Date: Fri, 29 Oct 2010 18:05:08 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Mark Johnston <markjdb@gmail.com> Subject: Re: Generating userland debugging symbols Message-ID: <AANLkTimXjj=GDXBEhTPwOTD38UL8iWEu2q4kbqePyDx-@mail.gmail.com> In-Reply-To: <20101029233900.GC2392@deviant.kiev.zoral.com.ua> References: <20101029191827.GC1443@mark-laptop-bsd.mark-home> <20101029233900.GC2392@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 29, 2010 at 4:39 PM, Kostik Belousov <kostikbel@gmail.com> wrot=
e:
> 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 containin=
g
>> 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 symbol=
s
>> 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 feedbac=
k.
>>
>> My basic idea is to add an option to /etc/src.conf that indicates that t=
he
>> build system should build all the userland programs with debugging symbo=
ls
>> 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?=3D/usr/local/lib/debug
>> STRIP_BIN:=3D"<program to perform the operation> ${SYMBOLS_DIR}"
>> .endif
>> .endif
>>
>> and then in bsd.prog.mk:
>>
>> .if defined(STRIP_BIN)
>> .PHONY:
>> =A0 =A0 =A0 export STRIPBIN=3D${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 w=
ith
--add-gnu-debuglink to create a two part executable. One=
a
stripped binary which will occupy less space in RAM and in a d=
is-
tribution and the second a debugging information file which is o=
nly
needed if debugging abilities are required. The suggested pro=
ce-
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=3Dfoo.dbg foo">
to add a link to the debugging info into the stripped e=
xe-
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 patche=
s.
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimXjj=GDXBEhTPwOTD38UL8iWEu2q4kbqePyDx->