From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 5 21:06:00 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 021D71065696 for ; Fri, 5 Nov 2010 21:06:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id ABC378FC22 for ; Fri, 5 Nov 2010 21:05:59 +0000 (UTC) Received: by gwj16 with SMTP id 16so2571156gwj.13 for ; Fri, 05 Nov 2010 14:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=S1F2/fIxkF/wBZG3/2Bh0S0HGLR+u+h3koUZ3Gk3vdE=; b=OWgq2F8A9H0ipbjSxD7JErUW2gvaKrYudHVKGFEesCxknb8/M5gJFSraLa123D86Fm i2kt8GHas9EjBBoeS+tuMdTiVt6SidAbGjk4fk6J31dIRjLyCmWK39SjxaxHGdd5EWRo joH5u8Rw/zRIzrMe6f/IiKmES3UKOm+g52rA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ta3lTP+8BIBf7RcY46dbc85mF9YN91BSR47raoLq6grp9OnVfsCof5LXmYtjJFTfDv T/YwSgqDxzOjCMUvHMS09mPrfzEbqgiQ1P3xYZi0w1Dw2hdXJHUHF0JwRVXm3RzYXetj PTjzaeqHpDYzr+hkfWJzlo0JO6sxFkrmqRKnI= Received: by 10.150.191.13 with SMTP id o13mr4222759ybf.235.1288991157027; Fri, 05 Nov 2010 14:05:57 -0700 (PDT) Received: from mark-laptop-bsd.mark-home (mail1.sandvine.com [64.7.137.162]) by mx.google.com with ESMTPS id q5sm2834207ybe.6.2010.11.05.14.05.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 14:05:56 -0700 (PDT) Date: Fri, 5 Nov 2010 17:05:38 -0400 From: Mark Johnston To: Gleb Kurtsou Message-ID: <20101105210538.GE1437@mark-laptop-bsd.mark-home> References: <20101105191443.GD1437@mark-laptop-bsd.mark-home> <20101105204519.GA2843@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101105204519.GA2843@tops> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Userland debug symbols directory X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 21:06:00 -0000 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