Date: Fri, 29 Oct 2010 21:58:35 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: Mark Johnston <markjdb@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Generating userland debugging symbols Message-ID: <AANLkTi=A%2BTfp7OyMf7b1MoWj1_qytYAZd=8Ux3HEjR15@mail.gmail.com> 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> <AANLkTimXjj=GDXBEhTPwOTD38UL8iWEu2q4kbqePyDx-@mail.gmail.com> <20101030021000.GA1328@mark-laptop-bsd.mark-home> <AANLkTinVXrUQa2dhcH2nzLKcg_Kfk1an3uLLSCgjdMRe@mail.gmail.com> <20101030033559.GA1387@mark-laptop-bsd.mark-home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 29, 2010 at 8:35 PM, Mark Johnston <markjdb@gmail.com> 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 <markjdb@gmail.com> 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.
<potentially unfounded philosophical rant>
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*.
</potentially unfounded philosophical rant>
>> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=A%2BTfp7OyMf7b1MoWj1_qytYAZd=8Ux3HEjR15>