On Fri, Oct 29, 2010 at 06:05:08PM -0700, Garrett Cooper wrote: > 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: > > The intention is that this option will be used in conjunction with > --add-gnu-debuglink to create a two part executable. One a > stripped binary which will occupy less space in RAM and in a dis- > tribution and the second a debugging information file which is only > needed if debugging abilities are required. The suggested proce- > dure to create these files is as follows: > > 1.<Link the executable as normal. Assuming that is is called> > "foo" then... > > 1.<Run "objcopy --only-keep-debug foo foo.dbg" to> > create a file containing the debugging info. > > 1.<Run "objcopy --strip-debug foo" to create a> > stripped executable. > > 1.<Run "objcopy --add-gnu-debuglink=foo.dbg foo"> > to add a link to the debugging info into the stripped exe- > cutable. > > That's probably similar to what your group is doing... > Of course a more generalized solution also might be smart if clang > / 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 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 the above operations in one command. I have no specific preference on this point though. I'm not familiar with pmake - I'll take a look into it. > > 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 show debug-file-directory and set debug-file-directory Thanks, -Mark _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
