Discussion:
[Bug gdb/22984] New: please add enhanced support for compressed separate debug_info files
jason.vas.dias at gmail dot com
2018-03-20 02:14:33 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=22984

Bug ID: 22984
Summary: please add enhanced support for compressed separate
debug_info files
Product: gdb
Version: HEAD
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---

Created attachment 10903
--> https://sourceware.org/bugzilla/attachment.cgi?id=10903&action=edit
basic simplest version that just checks if a compressed debug_info file exists
and uncompresses before loading if so

Please make gdb look for compressed versions of separate debug_info
files , and in some configurable location or list of such -


Reading the manual :

(gdb) Separate Debug Files

* For the "build ID" method, GDB looks in the '.build-id'
subdirectory of each one of the global debug directories for a file
named 'NN/NNNNNNNN.debug', where NN are the first 2 hex characters
of the build ID bit string, and NNNNNNNN are the rest of the bit
string. (Real build ID strings are 32 or more hex characters, not
10.)


Great! But, if it fails to find a file with plain '.debug' suffix,
and some new configuration variable eg. 'compressors' has a non-empty value,
then please let it try a list of expected extensions, eg. '.xz', '.gz', '.bz2'
... that map to configured compressors whose executable exists, eg
'/usr/bin/xz', '/usr/bin/gzip', '/usr/bin/bzip2', etc
and perhaps use the file command or run some script
to enable decompression of compressed separate debug_info
section files produced by:
$ objdump --only-keep-debug \
${binary_with_debuginfo} ${separate_debuginfo_file}


So, if *.debug does not exist, try a list of extensions that map
to decompression executables, and if one of those exists,
decompress the file to $(mktemp /tmp/${UID}_XXXXXX.debug_info)
or to a temporary file in some configured default writable directory .


I am attaching a patch that implements the version I use that,
if the .debug file does not exist, just checks if the
xz compressed .debug.xz file exists and if so, decompresses it
before loading - this could easily be extended to handle a list
of decompressors / a decompression script.

I need something like this feature so I can keep debug_info files
in compressed format.

It would also nice to have a default command-line argument or
environment variable setting to initialize 'debug-file-directory',
and this should automatically include the directory of the currently
loaded file, IMHO .
--
You are receiving this mail because:
You are on the CC list for the bug.
jason.vas.dias at gmail dot com
2018-03-20 02:53:46 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=22984

--- Comment #1 from Jason Vas Dias <jason.vas.dias at gmail dot com> ---
That patch is against 8.1.1 .

I need to apply it or something like it for each GDB rebuild.


Example output:

$ gcc -g -o hello hello.c
$ objcopy --only-keep-debug hello hello.debug
$ strip --keep-file-symbols hello
$ mkdir $PWD/.build-id
$ file hello
...BuildID[sha1]=b003de6398099b21398578f3c99bc3ecb0f1c05e,...
$ mkdir .build-id/b0
$ mv hello.debug .build-id/b0/03de6398099b21398578f3c99bc3ecb0f1c05e.debug
$ xz --compress .build-id/b0/03de6398099b21398578f3c99bc3ecb0f1c05e.debug
$ gdb -ex 'set debug-file-directory '$PWD
GNU gdb (GDB) 8.1
...
(gdb) file hello
Reading symbols from hello... Trying
/tmp/.build-id/b0/03de6398099b21398578f3c99bc3ecb0f1c05e.debug
Trying /tmp/.build-id/b0/03de6398099b21398578f3c99bc3ecb0f1c05e.debug.xz
Uncompressing: '/usr/bin/xz --uncompress <
/tmp/.build-id/b0/03de6398099b21398578f3c99bc3ecb0f1c05e.debug.xz >
/tmp/0_03de6398099b21398578.debug'.
Uncompression succeeded.Reading symbols from
/tmp/0_03de6398099b21398578.debug...done.
done.
(gdb) q
--
You are receiving this mail because:
You are on the CC list for the bug.
jason.vas.dias at gmail dot com
2018-03-20 12:16:02 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=22984

--- Comment #2 from Jason Vas Dias <jason.vas.dias at gmail dot com> ---
why when I specify gdb command line argument:
-ex 'set debug-file-directory ...'

does the setting of debug-file-directory not
take effect for files listed on command line ?

ie. why can't I say:
$ gdb -ex \
'set debug-file-directory ...' \
hello

When I do, my setting does not take effect and the
default debug-file-directory setting is used.

So I have to use 'file' command AFTER gdb loads, or
use a script file .

This is annoying!

Probably a more complete version of the patch would fix this
problem / provide a '--debug-file-directory=' command-line option
that is honored for command-line loaded files,
and a --disable-compression option, and a --with-debug-info-compression=yes|no
configuration option (default=yes) .

If I was to expand the patch to support the above, and a configurable
list of compression formats to try, would such a patch ever be considered
for inclusion in GDB ? it would be nice to know. Thanks, Jason
--
You are receiving this mail because:
You are on the CC list for the bug.
tromey at sourceware dot org
2018-04-01 17:00:25 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=22984

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
See the file gdb/CONTRIBUTE in the source tree for instructions on
how to submit a patch. In gdb, patch review is done on the mailing
list, not in bugzilla.

I'm curious to know how well the separate debug files actually compress,
and whether you tried either dwz or the binutils debuginfo compression
options. I think it would be good to mention that in the patch
email.

Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
tromey at sourceware dot org
2018-04-20 18:35:05 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=22984

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
Maybe a better resource is
https://sourceware.org/gdb/wiki/ContributionChecklist
--
You are receiving this mail because:
You are on the CC list for the bug.
Loading...