Hi this is an update for the prepstrip util to save split debug info. I'm submitting this by request of taviso from the security team. Often we developers need debug backtraces from users or on our own boxes. By default we strip away debug info and it's discarded forever. What the update does is objcopy the debug info out of the executable before stripping and then tags the orig binary with a .gnu_debuglink section. This section is used by any BFD aware program to autoload symbols when entering debug mode. Users wishing to not have debug info can simply use INSTALL_MASK="/usr/lib/debug" In an ideal world we would have subpackages and would leave a ${PF}-debug.tbz2 in PKGDIR= vs installing to the livefs till needed. (how every other distro does it) Everybody I spoke with thusfar about this general idea has been very supportive and has replaced the existing prepstrip with this updated one. Got a few people todo an -e world to make sure that it's safe for the next stable release. References: http://developer.apple.com/documentation/DeveloperTools/gdb/gdb/gdb_16.html#SEC137 ------------------------------------------------- And from the objcopy manpage. ------------------------------------------------- -only-keep-debug Strip a file, removing any sections that would be stripped by -strip-debug and leaving the debugging sections. 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 distribution and the second a debugging information file which is only needed if debugging abilities are required. The suggested procedure to create these files is as follows: 1. Link the executable as normal. Assuming that is is called foo then... 2. Run objcopy -only-keep-debug foo foo.dbg to create a file containing the debugging info. 3. Run objcopy -strip-debug foo to create a stripped executable. 4. Run objcopy -add-gnu-debuglink=foo.dbg foo to add a link to the debugging info into the stripped executable. Note - the choice of .dbg as an extension for the debug info file is arbitrary. Also the -only-keep-debug step is optional. You could instead do this: 1. Link the executable as normal. 2. Copy foo to foo.full 3. Run objcopy -strip-debug foo 4. Run objcopy -add-gnu-debuglink=foo.full foo ie the file pointed to by the -add-gnu-debuglink can be the full executable. It does not have to be a file created by the -only-keep-debug switch.
Created attachment 73132 [details] prepstrip (split debug) /usr/lib/portage/bin/prepstrip (it's eaiser to attach the full thing vs a patch) It depends on util scanelf from the pax-utils package which hopefully will be added to the depends for portage next release.
I'd like to see this happen (at least optionally). Be aware that this alternative split should also be in the path as some make scripts strip by themselves. One other point would be that it would be useful to change the location of the source files to for example /usr/src/pkgname (possibly conditional). I know that this is not really easy to do, but would be useful.
Yep, looking for this functionality to get included soon too. If you could post your patch on the existing bug and then discuss the differences there... *** This bug has been marked as a duplicate of 45150 ***
The path /usr/lib/debug was chosen as that is where gdb/BFD looks by default. It uses that path as the debug-file-directory and knows to load the symbols from the file basename pointed by the .gnu_debuglink section from -add-gnu-debuglink. In order to get it to load from another directory you would need to start the given program like LD_LIBRARY_PATH=/usr/lib/debug:/usr/src/pkgsrc gdb /path/to/foo Or optionaly use the 'symbol-file' option to read symbols from another dir.
Created attachment 73199 [details, diff] portage-2.0.53_rc7-debug-subpkg.patch As stated in a previous comment in an ideal world this would all become a subpkg. Attached is the code which does just that.
I have a hell of a time finding this bug as long as it remains a dupe.
As of pax-utils-0.1.5 we have support for *.a files. That obsoletes the need for the extra find statement in the prepstrip file but it's not in stable yet. We will try to fast track it so that the final split debug code that goes in .54 wont need the find statement at all.
erm, 0.1.5 was released to support scanning of .o files for gnu stack sections, not to scan .a files ... i'm pondering adding that support, but it isnt in yet
Released in 2.1_pre1.
What about adding support for changing the source location? And possibly storing the source code as well?
(In reply to comment #10) > What about adding support for changing the source location? You mean /usr/lib/debug? > And possibly storing the source code as well? tester has not made an ebuild for the debugedit yet as far as I can tell.
@solar#11: Something like /usr/lib/debug. Perhaps /usr/src/debug/${PN} or something similar. And indeed the debugedit ebuild ;-)
(In reply to comment #12) > @solar#11: Something like /usr/lib/debug. Perhaps /usr/src/debug/${PN} or > something similar. And indeed the debugedit ebuild ;-) If it's file space then a symlink would seem fitting. Using any dir other than /usr/lib/debug does not make sense to me. Being that is what the the BFD aware programs expect. Using a subdir of PN adds a bit of complexity and would require additional tagging in the elf that's going to be stripped. Can you please explain the motivation for this? If it's file space then a symlink would seem fitting. Otherwise I'd like to stick to standards.
The dir I point to is the location of source files. Currently the debug information expects those to be rooted at /var/tmp/portage/${PF}/work/${P}. If you look at bug #45150 it provides a debugedit binary that allows this location to be changed to be outside a temporary dir, and the files to be enumerated and copied to that outside dir. This makes debugging even easier.
(In reply to comment #14) > The dir I point to is the location of source files. Currently the debug > information expects those to be rooted at /var/tmp/portage/${PF}/work/${P}. If > you look at bug #45150 it provides a debugedit binary that allows this location > to be changed to be outside a temporary dir, and the files to be enumerated and > copied to that outside dir. This makes debugging even easier. Ok can we use bug #45150 for the debugedit and or open a new bug and call this one closed? The initial goals of this bug are complete.
Released in portage-2.1_pre3
I've added dev-util/debugedit to the tree and I've added my patch against the current SVN as attachment #76124 [details, diff] to bug #45150
(In reply to comment #17) > I've added dev-util/debugedit to the tree and I've added my patch against the > current SVN as attachment #76124 [details, diff] [edit] to bug #45150 Great thanks tester for putting debugedit in the tree. Can we wrapper this to a sub feature? like FEATURES="splitdebug debugedit" ?
Created attachment 76151 [details, diff] patch to use debugedit with feature alright, added feature "installsources".. best name I could come up with. Putting it here, too much crap on bug #45150
*** Bug 45150 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > alright, added feature "installsources".. best name I could come up with. InSVN -r2542
Released in 2.1_pre4
portage-2.0.54-r1 now contains splitdebug
