This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Support gzip compressed exec and core files in gdb
- From: Michael Eager <eager at eagerm dot com>
- To: Pedro Alves <palves at redhat dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, binutils <binutils at sourceware dot org>
- Date: Thu, 12 Mar 2015 08:34:03 -0700
- Subject: Re: [PATCH] Support gzip compressed exec and core files in gdb
- Authentication-results: sourceware.org; auth=none
- References: <54FF77D6 dot 7010400 at eagerm dot com> <20150311221329 dot GB11980 at host1 dot jankratochvil dot net> <5500E074 dot 6070002 at eagerm dot com> <55016D6F dot 4010104 at redhat dot com>
On 03/12/15 03:41, Pedro Alves wrote:
Waiting for GDB to decompress that once is already painful. Waiting for it
multiple times likely results in cursing and swearing at gdb's slow start
up. Smart users will realize that and end up decompressing the file manually
outside gdb, just once, anyway, thus saving time.
We could "fix" the "multiple times" issue by adding even more smarts,
based on an already-decompressed-files cache or some such. Though of
course, more smarts, more code to maintain.
I had considered adding a command or command line option to specify
the name of the uncompress file, so that it could be reused.
I agree with Jan -- The real convenience would be being able to skip the
long whole-file decompression step altogether, with an on-demand
block-decompress scheme, because gdb in reality doesn't need to touch
most of the vast majority of the core dump's contents. That would
be a solution that I'd be happy to see implemented.
That's a solution to a different problem.
If we're just decompressing to /tmp, then we also need to
compare the benefits of a built-in solution against having users
do the same with a user-provided gdb command implemented in one
of gdb's extensions languages (python, scheme), e.g., a command
that adds a "decompress-core" command that does the same:
decompresses whatever compression format, and loads the result
with "core /tmp/FILE".
This requires that users manually decompress files, and makes it
impossible to put the compressed file name on the command line.
It also looks to me like a wart and kludge, rather than having
GDB automatically identify the compression method and do the
operation transparently for the user.
IMO, whatever the solution, if built in, this is best implemented
in BFD, so that objdump can dump the same files gdb can.
I took that approach initially. But GDB finds and opens files,
not BFD. Moving what GDB is doing into BFD, where it should have
been in the first place (IMO), seemed more problematic.
Michael Eager email@example.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077