Generating userland debugging symbols

[Mark Johnston]

On Fri, Oct 29, 2010 at 07:48:31PM -0700, Garrett Cooper wrote:
> On Fri, Oct 29, 2010 at 7:10 PM, Mark Johnston <markjdb at gmail.com> wrote:
> > On Fri, Oct 29, 2010 at 06:05:08PM -0700, Garrett Cooper wrote:
> >
> > That's almost exactly what we're doing. I also think it's easier to go with a
> > script, but the required changes to strip(1) and install(1) are pretty
> > basic. strip(1) and objcopy(1) are both generated from the same source
> > file, so it's just a matter of adding an extra option that performs the
> > above operations in one command. I have no specific preference on this
> > point though.
> 
> Well.. perhaps, but this would impact the performance of standard make
> operations across the board, outside of FreeBSD make; trivially I'm
> sure, but it's just easier in this case probably to make it shell
> based and keep it confined to the FreeBSD build as it's a FreeBSD
> specific feature (unless the feature is truly useful enough and you
> can get enough folks on the bandwagon to standardize the feature) :/.
> 

I can't see how there'd be any performance difference - all I did was
add two options to strip(1), so that instead of pointing STRIPBIN to
a script that does

strip -o /usr/local/lib/debug/bin/foo.symbols --only-keep-debug /bin/foo
strip /bin/foo
objcopy --add-gnu-debuglink=foo.symbols /bin/foo

I can just use

STRIPBIN="strip -e --prefix-dir=/usr/local/lib/debug"

Currently, install(1) treats STRIPBIN as a program name; it essentially
does a execve(getenv(STRIPBIN)); my change just has it split any arguments
into an argv which then can be passed into execve. I'm not sure if this
change might be useful on its own.

On the whole, I agree that using a script for this is better though.
It'll make things easier to change later on, and it's less work to
maintain - I doubt my changes to strip(1) would be accepted upsteam
anyway, they don't implement any new functionality.

> > I'm not familiar with pmake - I'll take a look into it.
> 
> pmake is FreeBSD's make: http://www.freebsd.org/doc/en/books/pmake/

Ah... I'm still getting to know FreeBSD. =)
I'll take a look through the docs when I have some spare time this
weekend.

> 
> >>     I agree with kib@ on both counts and I like this idea. Maybe the
> >> directory should be something like /usr/obj/stripped for the stripped
> >> binaries and /usr/obj/debug for the debug symbols? (just something I'm
> >> tossing out... the hierarchy could be better organized than that..).
> >> It might get a bit more hairy to clean up later, but oh well, it's for
> >> development :D...
> >> Thanks!
> >> -Garrett
> >
> > It took me a while to figure this out, but the absolute path to the
> > debug symbols isn't encoded in the .gnu_debuglink segment - just the
> > filename is placed there. When gdb loads a binary, it searches a
> > predefined set of directories for the file recorded in .gnu_debuglink
> > and loads it if it finds it. One of the directories is global - on
> > FreeBSD it seems to be /usr/local/lib/debug/ by default. You can
> > configure it with
> 
>     Hmmm... didn't realize it all went there. What about cases with
> compat libraries where we need versioning?

That's a good point. Symbols files for libraries should be named by
version, so that, say, /lib/libc.so.7 would have its gnu_debuglink point
to /usr/local/lib/debug/lib/libc.7.symbols. Is this what you're
referring to?

Thanks,
-Mark