Date: Fri, 29 Oct 2010 19:48:31 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: Mark Johnston <markjdb@gmail.com> Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-hackers@freebsd.org Subject: Re: Generating userland debugging symbols Message-ID: <AANLkTinVXrUQa2dhcH2nzLKcg_Kfk1an3uLLSCgjdMRe@mail.gmail.com> In-Reply-To: <20101030021000.GA1328@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >> =A0 =A0 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: >> >> =A0 =A0 =A0 =A0 =A0 =A0The =A0intention is that this option will be used= in conjunction with >> =A0 =A0 =A0 =A0 =A0 =A0--add-gnu-debuglink =A0to =A0create =A0a =A0two = =A0part =A0executable. =A0 One =A0a >> =A0 =A0 =A0 =A0 =A0 =A0stripped =A0binary =A0which will occupy less spac= e in RAM and in a dis- >> =A0 =A0 =A0 =A0 =A0 =A0tribution and the second a debugging information = file which is only >> =A0 =A0 =A0 =A0 =A0 =A0needed =A0if =A0debugging abilities are required.= =A0The suggested proce- >> =A0 =A0 =A0 =A0 =A0 =A0dure to create these files is as follows: >> >> =A0 =A0 =A0 =A0 =A0 =A01.<Link the executable as normal. =A0Assuming tha= t is is called> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"foo" then... >> >> =A0 =A0 =A0 =A0 =A0 =A01.<Run "objcopy --only-keep-debug foo foo.dbg" to= > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0create a file containing the debugging in= fo. >> >> =A0 =A0 =A0 =A0 =A0 =A01.<Run "objcopy --strip-debug foo" to create a> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0stripped executable. >> >> =A0 =A0 =A0 =A0 =A0 =A01.<Run "objcopy --add-gnu-debuglink=3Dfoo.dbg foo= "> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to add a link to the debugging =A0info = =A0into =A0the =A0stripped =A0exe- >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cutable. >> >> =A0 =A0 That's probably similar to what your group is doing... >> =A0 =A0 Of course a more generalized solution also might be smart if cla= ng >> / 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?). > > That's almost exactly what we're doing. I also think it's easier to go wi= th 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 the > 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'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/ >> =A0 =A0 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 > > 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 Hmmm... didn't realize it all went there. What about cases with compat libraries where we need versioning? > show debug-file-directory > and > set debug-file-directory Nifty.. didn't know about those commands :). Sure a lot easier than setting the solib-absolute-path garbage was. Thanks! -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinVXrUQa2dhcH2nzLKcg_Kfk1an3uLLSCgjdMRe>