Re: Automatic debug symbol generation

[Ralf Wildenhues]

* 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).

> > > It was just an example.  Other platforms would use otool or LINK, of
> > > course.

> Oops, it's actually dsymutil on the mac, sorry:

Thanks.

>   
> http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man1/dwarfdump.1.html#//apple_ref/doc/man/1/dwarfdump
> 
> On Windows, the debugging files are called .PDBs, so you say LINK /PDB
> to get a separate PDB file with the debugging symbols.

Ah, ok.

> > What about AIX, HP-UX, Solaris, IRIX (well...)?
> 
> 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.

> > 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.

Cheers,
Ralf