Date: Fri, 5 Nov 2010 17:05:38 -0400 From: Mark Johnston <markjdb@gmail.com> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Userland debug symbols directory Message-ID: <20101105210538.GE1437@mark-laptop-bsd.mark-home> In-Reply-To: <20101105204519.GA2843@tops> References: <20101105191443.GD1437@mark-laptop-bsd.mark-home> <20101105204519.GA2843@tops>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: > On (05/11/2010 15:14), Mark Johnston wrote: > > Hi all, > > > > I have some tentative patches which add support for creating a separate > > directory containing all of the userland debugging symbols. > > > > I posted about this a week or so ago: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-October/033437.html > > > > Some future work will involve finding out if any changes are necessary to > > support Clang/LLVM, and seeing whether there's any interest in adding > > support to the FreeBSD installer to install the debug symbols to a > > user-defined directory. > > > > Note that DEBUG_FLAGS must be set somewhere when building world - > > adding WITH_DEBUG_SYMBOLS_DIR=yes to src.conf beforehand is sufficient, > > as it causes DEBUG_FLAGS+=-g to be set; building world with DEBUG_FLAGS=-g > > alone is also sufficient. If the binaries are built without debug symbols > > and one tries to use my new option, nothing happens, i.e., no new > > files/directories are created, unless specific programs explicitly > > build with -g somehow (see below). > Hi, > > I like the idea a lot, but why not to leave symbol files in /usr/obj, > otherwise it creates a problem of mismatch between installed binaries > and stale symbol files. Kernel case is very different, it preserves > previous version during 'make installkernel' besides one would hardly > need symbols for all installed binaries. It's for developers only after > all. If there is a problem to be debugged one can always find binary > and corresponding symbols file under /usr/obj. When the .gnu_debuglink segment is added to a binary, it doesn't contain a full path to the .symbols file - it just contains the name. It's gdb that looks for debug symbols files: http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html In particular, gdb looks in /usr/local/lib/debug by default: mark: ~/docs$ gdb (gdb) show debug-file-directory The directory where separate debug symbols are searched for is "/usr/local/lib/debug". I have no problem using a different directory, but users would have to remember to configure it to use a different path. > > My changes are below. There's a new file (stripbin.sh) which invokes > > objcopy(1) and strip(1). At the moment it's in usr/src, but it should > > probably go elsewhere... perhaps usr/src/tools? The other changes are to > > bsd.prog.mk, bsd.own.mk and the src.conf man page. > > > > I've also noticed a few Makefiles that explicitly set DEBUG_FLAGS=-g > > or CFLAGS+=-g for some reason. They are in > > > > usr.bin/tar/ > > cddl/usr.bin/ctfconvert/ > > cddl/usr.sbin/usr.sbin/lockstat/ > > usr.sbin/wpa/wpa_supplicant/ > > usr.sbin/wpa/hostapd/ > > usr.sbin/bluetooth/bthidd/ > > > > I'm not sure if this is intentional. > > > > Feedback and suggestions are extremely welcome. =) > > > > Thanks, > > -Mark > > > > diff --git a/stripbin.sh b/stripbin.sh > > new file mode 100755 > > index 0000000..be2e9ad > > --- /dev/null > > +++ b/stripbin.sh > > @@ -0,0 +1,29 @@ > > +#!/bin/sh > > + > > +# This script is invoked by install(1) on all binaries when installing world. > > +# It determines whether any debug info is present in the binary; if so, it > > +# will extract the debug symbols to $SYMBOLS_FULLPATH, strip the binary and > > +# add a link to the binary which points to the file containing the debugging > > +# symbols. > > + > > +: ${READELFEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/readelf/readelf} > > +: ${STRIPEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/strip/strip} > > +: ${OBJCEXEC:=/usr/obj/usr/src/gnu/usr.bin/binutils/objcopy/objcopy} > > +: ${DIRNAMEEXEC:=/usr/obj/usr/src/usr.bin/dirname/dirname} > Did it survive make universe? Looks incorrect for me. At least you > should depend on binaries which are part of the build toolchain, and not > hard code paths. > Ah, I forgot about that target; I'll give it a try tonight. As for the hard-coded paths, that's really an artifact of what's done in the tree at my work. We do FreeBSD builds by copying over a pre-defined set of binaries and libraries to the build server, copying the sources, and building in a chroot. Hard-coding the paths just ensures that the programs are actually there. I suppose this is not necessary in general though; does it make sense to assume that the above tools will always be available in PATH? > I'd propose not to add any scripts and handle it within makefiles. That was my original goal, but it's much more difficult to accomplish. As described in the install(1) man page, install(1) invokes the value of STRIPBIN (if set) on its input if -s is passed in. AFAIK, there's no way to accomplish what I want - extract symbols, strip the binary, and add debuglink - with a single command. I tried adding some extra options to strip(1) to do it, and it turned into something of a mess - it was discussed a bit in the original thread. Thanks, -Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101105210538.GE1437>