Generating userland debugging symbols

[Garrett Cooper]

On Fri, Oct 29, 2010 at 4:39 PM, Kostik Belousov <kostikbel at gmail.com> wrote:
> On Fri, Oct 29, 2010 at 03:18:27PM -0400, Mark Johnston wrote:
>> Hello all,
>>
>> I've been working on some changes to the system build scripts that make
>> it easier to create and install debugging symbols files for the base
>> userland. What we do in the tree at my work (Sandvine) is use a script
>> that invokes strip(1) and objcopy(1) to create a separate file containing
>> the debugging symbols for each binary; so for example, the symbols for
>> /bin/ls get placed in another directory, e.g.
>> /usr/local/lib/debug/bin/ls.symbols.
>>
>> The name of the symbols file for each binary is encoded in the
>> .gnu_debuglink segment; when gdb comes across it, it searches a set
>> of directories for the debug symbols file and loads it if found.
>>
>> It turns out to be pretty convenient - one can keep the debugging symbols
>> on a separate slice or on an NFS-mounted directory if space is an issue,
>> or package the debug symbols separately and keep them on an FTP server,
>> ready to install if needed.
>>
>> I'm not aware of any infrastructure in place that makes it easy to do
>> this for the userland programs. What I'm hoping to find out is whether
>> there's any interest in adding such support. I've discussed this with
>> Ed Maste to some degree, but it'd be nice to get some additional feedback.
>>
>> My basic idea is to add an option to /etc/src.conf that indicates that the
>> build system should build all the userland programs with debugging symbols
>> and later extract them. So a user would define something like
>> WITH_DEBUG_SYMBOLS in src.conf, and then in bsd.own.mk, have something
>> like
>>
>> .if !defined(_WITHOUT_SRCCONF)
>> .if defined(WITH_DEBUG_SYMBOLS)
>> SYMBOLS_DIR?=/usr/local/lib/debug
>> STRIP_BIN:="<program to perform the operation> ${SYMBOLS_DIR}"
>> .endif
>> .endif
>>
>> and then in bsd.prog.mk:
>>
>> .if defined(STRIP_BIN)
>> .PHONY:
>>       export STRIPBIN=${STRIP_BIN}
>> .endif
>>
>> so that when install(1) gets run, STRIPBIN will be in the environment.
>>
>> In our setup, STRIPBIN points to a script which just uses strip(1) and
>> objcopy(1) to extract the debug symbols for each binary that gets
>> installed. Ed suggested that I could just add an option to strip(1) to
>> do all of this in one command so that we wouldn't need to add a separate
>> script to the FreeBSD tree for this. It's pretty simple to do - I can
>> post the patch if anyone wants to see it. This also requires a smallish
>> change to install(1) which I can also post.

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

>> Any thoughts or suggestions on this approach in general? I'm still
>> getting to know the FreeBSD system, so I'm open to alternatives. If
>> there's agreement that this feature might be useful, I'll post my patches.
> I do think that something like this would be useful. But, shouldn't
> the DEBUG_FLAGS be also involved in the patch ? The goal would be
> to have debug symbols for userland staff. esp. the libraries,
> handled in a similar manner to kernel symbols.
>
> But I do like the intent of keeping the symbols in the separate directory.

    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