Re: Automatic debug symbol generation

[Jason Spence]

On Wed, Apr 22, 2009 at 07:33:47AM +0200, Ralf Wildenhues wrote: 
> Hello,
> 
> * 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.  

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.

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.

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

> Just get the git tree here:
> 
>   git clone git://git.sv.gnu.org/automake.git
>   cd automake
>   ./bootstrap
> 
> and then get hacking.  README, tests/README contain information about
> testing, the HACKING file contains information on what is requires for
> patches to be applicable.  And yes, we'd prefer full test exposure for
> all new features.

Ah, that was what I needed to have.  Thanks.