| Message ID | 1411632395-10516-1-git-send-email-olaf@aepfle.de |
|---|---|
| State | New |
| Headers | show |
On 25 September 2014 09:06, Olaf Hering <olaf@aepfle.de> wrote: > During code review for xen I noticed that --enable-debug-info would > still strip the binaries because strip_opt= defaults to yes. > If --enable-debug-info is passed to configure it has to be assumed > that not only the compiled binaries have debugsymbols, also the > installed binaries should keep the symbols. The requirement to pass > also --disable-strip looks odd. I think defaulting to build with debug but strip on install makes sense. It follows for example how Debian recommend building things: https://www.debian.org/doc/debian-policy/ch-files.html and means that your installed binaries don't have the extraneous debug info but you can keep the build tree to make sense of backtraces etc later. I also prefer configure's options to be orthogonal: --enable-debug-info should only change how we deal with debug info, and not also have an effect on whether we strip it on install. (Plus your patch as it stands means that the behaviour you get by default now differs from the behaviour if you explicitly say --enable-debug-info.) thanks -- PMM
On Thu, Sep 25, Peter Maydell wrote: > On 25 September 2014 09:06, Olaf Hering <olaf@aepfle.de> wrote: > > During code review for xen I noticed that --enable-debug-info would > > still strip the binaries because strip_opt= defaults to yes. > > If --enable-debug-info is passed to configure it has to be assumed > > that not only the compiled binaries have debugsymbols, also the > > installed binaries should keep the symbols. The requirement to pass > > also --disable-strip looks odd. > > I think defaulting to build with debug but strip on install > makes sense. It follows for example how Debian recommend > building things: > https://www.debian.org/doc/debian-policy/ch-files.html > and means that your installed binaries don't have the > extraneous debug info but you can keep the build tree > to make sense of backtraces etc later. make install DESTIDIR=$RPM_BUILD_ROOT will also remove debug symbols, even if the rpmbuild helper scripts would be able to extract them into a separate -debuginfo package. So will --disable-strip remain for ever? Can I depend on that? Olaf
On Thu, Sep 25, 2014 at 10:06:35AM +0200, Olaf Hering wrote: > During code review for xen I noticed that --enable-debug-info would > still strip the binaries because strip_opt= defaults to yes. > If --enable-debug-info is passed to configure it has to be assumed > that not only the compiled binaries have debugsymbols, also the > installed binaries should keep the symbols. The requirement to pass > also --disable-strip looks odd. Perhaps package maintainers rely on installed binaries not having debug symbols? It's common to split the debug symbols into separate ELF files that are shipped in a different package (qemu-debuginfo or similar). If you make this change and packagers are unaware, they could accidentally ship qemu packages that contain the full debug symbols in the binaries. That said, I don't really know... The package maintainers can give you a definitive answer whether or not this is a good thing to do. Stefan
On 25 September 2014 11:47, Olaf Hering <olaf@aepfle.de> wrote: > On Thu, Sep 25, Peter Maydell wrote: > So will --disable-strip remain for ever? Can I depend on that? We're not planning to remove it, certainly. We don't make strong guarantees about configure commandlines remaining stable across QEMU versions but we aren't going to gratuitously break them either. (If you're a distro packager it's probably good practice to scan the configure help output for new option flags you might want to explicitly enable/disable for new versions anyway, though.) -- PMM
On Thu, Sep 25, Stefan Hajnoczi wrote: > If you make this change and packagers are unaware, they could > accidentally ship qemu packages that contain the full debug symbols in > the binaries. rpm will take care of that all by itself. Olaf
25.09.2014 14:49, Stefan Hajnoczi wrote: [] > Perhaps package maintainers rely on installed binaries not having debug > symbols? Package maintainer can and _should_ watch for changes in new releases and update their packages to accomodate changes made upstream. > It's common to split the debug symbols into separate ELF files that are > shipped in a different package (qemu-debuginfo or similar). We was thinking about shipping these in debian (currently we don't build with debug info enabled), but it turned out to be rather problematic due to amount of binaries and size of the symbols. I still consider enabling debug info for at least x86 system targets (as most widely used). Either way, in debian we strip executables outside of upstream build system usually. > If you make this change and packagers are unaware, they could > accidentally ship qemu packages that contain the full debug symbols in > the binaries. And it will be their problem entirely, especially if they wont notice the size difference :) No, really, this is not something an upstream should think too much about. Thanks, /mjt
Il 25/09/2014 12:49, Stefan Hajnoczi ha scritto: > On Thu, Sep 25, 2014 at 10:06:35AM +0200, Olaf Hering wrote: >> During code review for xen I noticed that --enable-debug-info >> would still strip the binaries because strip_opt= defaults to >> yes. If --enable-debug-info is passed to configure it has to be >> assumed that not only the compiled binaries have debugsymbols, >> also the installed binaries should keep the symbols. The >> requirement to pass also --disable-strip looks odd. > > Perhaps package maintainers rely on installed binaries not having > debug symbols? If so, that should be taken care of by the distribution. Of course, a distribution is free to separate the debug info and ship it as a separate package; in that case, it makes sense to distribute stripped binaries. But I think discarding symbols on "make install" is in general a bad idea, especially for long-lived processes such as QEMU where you often have non-reproducible bugs. If symbols are gone, even the simplest bug becomes basically impossible to diagnose from a core dump. The GNU Makefile standards have "make install" and "make install-strip" targets. It would be nice to add "make install-strip" and at the same time flip the default from --enable-strip to --disable-strip. Paolo
On Thu, Sep 25, 2014 at 03:51:44PM +0200, Paolo Bonzini wrote: > The GNU Makefile standards have "make install" and "make > install-strip" targets. It would be nice to add "make install-strip" > and at the same time flip the default from --enable-strip to > --disable-strip. Makes sense. Stefan
diff --git a/configure b/configure index 862f6d2..1fd5c6b 100755 --- a/configure +++ b/configure @@ -357,6 +357,7 @@ for opt do EXTRA_LDFLAGS="$optarg" ;; --enable-debug-info) debug_info="yes" + strip_opt="no" ;; --disable-debug-info) debug_info="no" ;;
During code review for xen I noticed that --enable-debug-info would still strip the binaries because strip_opt= defaults to yes. If --enable-debug-info is passed to configure it has to be assumed that not only the compiled binaries have debugsymbols, also the installed binaries should keep the symbols. The requirement to pass also --disable-strip looks odd. Signed-off-by: Olaf Hering <olaf@aepfle.de> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Michael Tokarev <mjt@tls.msk.ru> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Stefan Weil <sw@weilnetz.de> --- configure | 1 + 1 file changed, 1 insertion(+)