Re: Automatic debug symbol generation

[JRS]

On Sat, Apr 25, 2009 at 10:01:18AM +0200, Ralf Wildenhues wrote: 
> Well, one important bit for features that Automake aims to offer is
> that, while we don't mind exploiting the better functionality present
> on powerful systems like GNU/Linux, we would like to be able to degrade
> gracefully on less powerful ones.  A `strip' program of some sort is
> present on most systems (but it might produce unusable output, at least
> with libraries), and using that, or just not stripping, is a graceful
> degradation for the functionality `make install-strip' offers.
> 
> 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.

> > > Also, objcopy is not portable to anything that doesn't have GNU
> > > binutils.
> > 
> > It was just an example.  Other platforms would use otool or LINK, of
> > course.
> 
> Thanks.  I don't know either of those tools very well.  The manpage that
> I found for otool,
> <http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/otool.1.html>
> doesn't tell me how to either strip debugging symbols, nor how to keep
> only debugging symbols.  The documentation I find about LINK,
> <http://msdn.microsoft.com/en-us/library/y0zzbyt4.aspx>
> tells me how to generate debugging information, but not whether that
> would be separate from the program binary or as part of it, nor how to
> generate debugging information without generating a program binary.

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

  
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.

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

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