Generating userland debugging symbols
Garrett Cooper
gcooper at FreeBSD.org
Sat Oct 30 02:48:33 UTC 2010
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:
>> But having a strip script might be useful. Some companies brand
>> binaries for their own purposes, so having a hook into a strip script
>> (it should be no more than a few lines), should suffice. Something
>> that my old group used was similar to what's described in the objcopy
>> manpage:
>>
>> The intention is that this option will be used in conjunction with
>> --add-gnu-debuglink to create a two part executable. One a
>> stripped binary which will occupy less space in RAM and in a dis-
>> tribution and the second a debugging information file which is only
>> needed if debugging abilities are required. The suggested proce-
>> dure to create these files is as follows:
>>
>> 1.<Link the executable as normal. Assuming that is is called>
>> "foo" then...
>>
>> 1.<Run "objcopy --only-keep-debug foo foo.dbg" to>
>> create a file containing the debugging info.
>>
>> 1.<Run "objcopy --strip-debug foo" to create a>
>> stripped executable.
>>
>> 1.<Run "objcopy --add-gnu-debuglink=foo.dbg foo">
>> to add a link to the debugging info into the stripped exe-
>> cutable.
>>
>> That's probably similar to what your group is doing...
>> Of course a more generalized solution also might be smart if clang
>> / llvm decides to go off in a completely different direction
>> syntactically from binutils. Hence a custom tailored set of scripts
>> may or may not be the way to go (is pmake's .USE directive another
>> option?).
>
> 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'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/
>> 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?
> show debug-file-directory
> and
> set debug-file-directory
Nifty.. didn't know about those commands :). Sure a lot easier
than setting the solib-absolute-path garbage was.
Thanks!
-Garrett
More information about the freebsd-hackers
mailing list