From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 30 04:58:37 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 B353E1065672 for ; Sat, 30 Oct 2010 04:58:37 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9DA8FC12 for ; Sat, 30 Oct 2010 04:58:36 +0000 (UTC) Received: by wyb42 with SMTP id 42so3788528wyb.13 for ; Fri, 29 Oct 2010 21:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=j8+nxyEWeWYzkADLDxMURLbeME59k4/4t2Ebv8KTMjw=; b=f/pw+pG8fbtnLEarUUkj49jPnSKhZ0iKgqPyPEc5DyYS0Ud02+Cv+CHci/4cAkkbuf /8O+2RD8+jf6udcCevTnSxfrX8Xv2+LRaHCiyzWqB1krQ81aLPYJ85P7qJXDK5Vedw2p pShor6ZY0gblYExeAs91TMLVyMFke4yddWDTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EEquLbV4JziBrZB5FpFnWdA1gijlMNl6ns2QIfDwX3MccU4jw7i0H3ziVQy3d1UZ3z 6x1muNuA68zCL06pT8209f3H2xmJq1EUwgOct7L/YocICaOJXIGW9rpNh0cnKyoYHE7H IYarzm0w2CIeVrhb04sus+z6cfUeZpmpji3eA= MIME-Version: 1.0 Received: by 10.216.172.9 with SMTP id s9mr12904286wel.56.1288414715599; Fri, 29 Oct 2010 21:58:35 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Fri, 29 Oct 2010 21:58:35 -0700 (PDT) In-Reply-To: <20101030033559.GA1387@mark-laptop-bsd.mark-home> References: <20101029191827.GC1443@mark-laptop-bsd.mark-home> <20101029233900.GC2392@deviant.kiev.zoral.com.ua> <20101030021000.GA1328@mark-laptop-bsd.mark-home> <20101030033559.GA1387@mark-laptop-bsd.mark-home> Date: Fri, 29 Oct 2010 21:58:35 -0700 X-Google-Sender-Auth: T9HfxsTxhus-8RhUSDKC1CMsUJc Message-ID: From: Garrett Cooper To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Generating userland debugging symbols 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: Sat, 30 Oct 2010 04:58:37 -0000 On Fri, Oct 29, 2010 at 8:35 PM, Mark Johnston wrote: > On Fri, Oct 29, 2010 at 07:48:31PM -0700, Garrett Cooper wrote: >> On Fri, Oct 29, 2010 at 7:10 PM, Mark Johnston wrote= : >> > On Fri, Oct 29, 2010 at 06:05:08PM -0700, Garrett Cooper wrote: >> > >> > 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 th= e >> > 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 can't see how there'd be any performance difference - all I did was > add two options to strip(1), so that instead of pointing STRIPBIN to > a script that does > > strip -o /usr/local/lib/debug/bin/foo.symbols --only-keep-debug /bin/foo > strip /bin/foo > objcopy --add-gnu-debuglink=3Dfoo.symbols /bin/foo > > I can just use > > STRIPBIN=3D"strip -e --prefix-dir=3D/usr/local/lib/debug" > > Currently, install(1) treats STRIPBIN as a program name; it essentially > does a execve(getenv(STRIPBIN)); my change just has it split any argument= s > into an argv which then can be passed into execve. I'm not sure if this > change might be useful on its own. > > On the whole, I agree that using a script for this is better though. > It'll make things easier to change later on, and it's less work to > maintain - I doubt my changes to strip(1) would be accepted upsteam > anyway, they don't implement any new functionality. Yeah. The Unix philosophy typically aligns itself with simplicity in construction, which isn't always simplicity in execution (that's OSX / Windows / etc). Simplicity in execution typically involves complexity, which can make code tricky and unmanageable longterm... *cough*. >> > 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/ > > Ah... I'm still getting to know FreeBSD. =3D) > I'll take a look through the docs when I have some spare time this > weekend. man make too :) (yes, we have manpages unlike some other Unix clones out there :P..). >> > 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 >> >> =A0 =A0 Hmmm... didn't realize it all went there. What about cases with >> compat libraries where we need versioning? > > That's a good point. Symbols files for libraries should be named by > version, so that, say, /lib/libc.so.7 would have its gnu_debuglink point > to /usr/local/lib/debug/lib/libc.7.symbols. Is this what you're > referring to? The easiest way to look at this is to install /usr/ports/misc/compat*x ; IronPort (my employer) does some potentially `clever' linker lookup tricks to determine which compat libs to load, but vanilla FreeBSD for the most part jams all of the libs into /usr/local/lib/compat/ -- which unfortunately means that you lose versioning between minor versions of FreeBSD *shrugs*. Anyhow... hope that helps fill in some gaps :). Thanks! -Garrett