[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automatic debug symbol generation

From: JRS
Subject: Re: Automatic debug symbol generation
Date: Mon, 27 Apr 2009 14:19:41 -0700
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Apr 27, 2009 at 09:47:42PM +0200, Ralf Wildenhues wrote: 
> * JRS wrote on Sat, Apr 25, 2009 at 11:23:13PM CEST:
> > On Sat, Apr 25, 2009 at 10:01:18AM +0200, Ralf Wildenhues wrote: 
> > > I don't yet see how degrading gracefully is easily possible with the
> > > functionality you propose, as a program to remove all but the debug
> > > symbols is AFAIK not present on many systems.  Would you just want to
> > > install another full copy of the program, now including debugging
> > > symbols?
> > 
> > I think my proposal could have been more clear: the idea is to install
> > a separate file which contains only debugging symbols and no
> > executable code.  This way you can fire up the debugger and tell it to
> > debug stripped binary A using debug symbol file B.  strip isn't
> > involved.
> > 
> > As far as degrading gracefully, automake could simply emit a no-op
> > version of the install-symbols (or whatever) target when it detects
> > that the build system doesn't have the necessary tools to create a
> > separate debug symbol package.  The target would then warn the user
> > that the target had no effect and to make it do something they're
> > going to have to autoreconf after installing the necessary tools.
> Hmm.  That's degradation alright, but with a rather low level of grace.
> Still, the approach you have outlined would not address Bob's issue of
> slow install due to large unstripped file even in the best case (where
> all the necessary tools are available).

True, and that's going to remain the way it is.  Nothing lost, nothing
gained.  I don't think that invalidates the justification I gave via
the other use cases though.

It just occurred to me that instead of copying the symbol data, cygwin
users could point the debugger at the original unstripped files.  That
way the install process only copies the executables which might save
some time.

> > It's my understanding that ELF platforms can all do this, but the
> > native tools may not support generating or using the external debug
> > symbol files.
> Which of course still amounts to the us not being able to provide it
> without GNU binutils.

It's only useful if your debugger supports loading symbols from a
separate file anyway, so platforms with native toolchains that can't
do that shouldn't miss anything.  If they do have gdb installed, I
think it's likely they can get (or already have) binutils as well.

> > > Bob and Jan mention that w32 is one of the systems where debugging
> > > information can be huge (is that w32-specific or just MinGW-specific?)
> > > and where running programs with debugging information can be slowed down
> > > a lot by this.  If this is such a big problem on this system, would it
> > > be possible to work on the compiler and link editor to create smaller
> > > debugging symbol sections?  Put another way, why are those files so big
> > > in the first place?
> > 
> > I know that PDB is a little verbose, but I just checked my local
> > cygwin install and it looks like objcopy --only-keep-debug outputs a
> > PE object with STABS.  I'm not sure why these would be very large, but
> > you might be right about fixing the tools.
> > However, the cases I described above aren't Windows specific.
> But one motivation to handle this seems to be.
> Another important question is this: do various systems/distributions
> etc. already deal with this issue, and if yes, do they do so in ways
> different from the one you're proposing?  Point here is that, while we
> don't have a problem with exploring new ways of doing things, we should
> be a bit more cautious in trying to impose policy in those cases where
> multiple incompatible ones are already practiced on different systems.
> In that case, such a strategy is likely to produce more problems, rather
> than less.
> IOW, iff there are already multiple such policies, then the first step
> would be to talk to the people implementing them and try to find an
> acceptable compromise for all.

Redhat and Debian derived distributions ship -debug and -dbg packages
which put symbol-only files under /usr/lib/debug.  A quick check shows
that cygwin and a few other exotic unixes don't seem to have any
precedent -- the standard thing to do is to just install unstripped
binaries.  If that's true, then autotools could set a precedent for
those platforms.

This seems to be a de facto thing, because the FHS doesn't mention it.

My personal experience is that this convention is pretty well
entrenched on most Linuxes, and some projects have tools which expect it:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]