Re: Automatic debug symbol generation

[Ralf Wildenhues]

Hello Jason, all,

* Jason Spence wrote on Wed, Apr 22, 2009 at 08:01:20AM CEST:
> On Wed, Apr 22, 2009 at 07:33:47AM +0200, Ralf Wildenhues wrote: 
> > * JRS wrote on Wed, Apr 22, 2009 at 07:02:55AM CEST:
> > > I was setting up build infrastructure once again when it occurred to
> > > me, hmm, wouldn't it be nice if automake had default targets for
> > > installing symbols?
> > > 
> > > For example, make install-syms could do objcopy --only-keep-debug on
> > > the binaries and libraries, and put the .debug files in
> > > /usr/lib/debug.
> > 
> > What's the advantage over just installing binaries into $(bindir)
> > without stripping them?  Non-brain-damaged systems won't load them from
> > the file anyway for normal execution.
> 
> I have two uses cases in mind:
> 
> 1) Embedded systems development.  Sometimes your dev board is the same
> as your shipping board, and the storage is limited and not
> replaceable.  Some of these devices don't have network interfaces for
> NFS either.  

I'm not sure whether you are aware of it, but automake provides a `make
install-strip' rule that installs binaries without debugging symbols.
However, it does so by using the install-sh script which installs
binaries first, then strips them; see the strip.m4 source file for a
rationale for this:
<http://git.savannah.gnu.org/cgit/automake.git/tree/m4/strip.m4>.

> 2) For groups that release their own packages, shipping the debug
> symbols unconditionally in every download can translate into a
> significant amount of bandwidth.  If the package is mainly used by
> users who don't know which end of the debugger is which, most of those
> downloaded symbol bits aren't going to get used and it might be more
> cost effective to just provide those packages separately.

Sure.

> The counterargument to 2) is that whoever's on package duty should
> separate the debug information themselves, but then you have all the
> packagers reinventing the wheel instead of factoring out the necessary
> logic into autotools.
> 
> In particular, I'm thinking of buildroot.  I think adding automatic
> debug symbol generation to all the packages would be a large patch,
> whereas adding that feature via autotools instead would result in a
> smaller patch.

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?

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

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

Thanks,
Ralf