Generating userland debugging symbols

[Garrett Cooper]

On Fri, Oct 29, 2010 at 8:35 PM, Mark Johnston <markjdb at gmail.com> wrote:
> 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.

    Yeah.

<potentially unfounded philosophical rant>
    The Unix philosophy typically aligns itself with simplicity in
construction, which isn't always simplicity in execution (that's OSX /
Windows / etc). Simplicity in execution typically involves complexity,
which can make code tricky and unmanageable longterm... *cough*.
</potentially unfounded philosophical rant>

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

man make too :) (yes, we have manpages unlike some other Unix clones
out there :P..).

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

    The easiest way to look at this is to install
/usr/ports/misc/compat*x ; IronPort (my employer) does some
potentially `clever' linker lookup tricks to determine which compat
libs to load, but vanilla FreeBSD for the most part jams all of the
libs into /usr/local/lib/compat/ -- which unfortunately means that you
lose versioning between minor versions of FreeBSD *shrugs*.
    Anyhow... hope that helps fill in some gaps :).
Thanks!
-Garrett