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: Jan Kratochvil <jan dot kratochvil at redhat dot com>, Doug Evans <dje at google 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:24:27 -0700
- Subject: Re: [PATCH] Support gzip compressed exec and core files in gdb
- Authentication-results: sourceware.org; auth=none
- References: <20150312045436 dot GA31225 at host1 dot jankratochvil dot net>
On 03/11/15 21:54, Jan Kratochvil wrote:
On Thu, 12 Mar 2015 00:14:21 +0100, Doug Evans wrote:
On Wed, Mar 11, 2015 at 3:13 PM, Jan Kratochvil
ISTM libz-gzip and liblzma-xz compatibility is mutually exclusive.
Can you elaborate?
That gzip decompression can be done by libz but libz cannot decompress xz.
The xz decompression can be done by liblzma but liblzma cannot decompress
Therefore supporting both gzip and xz formats needs two functions / two
libraries / two APIs support in GDB.
A different decompression library is needed for each compression type.
Adding another decompression method would be simple.
Then I do not understand why to support gzip in the first place.
We have exec and core files which are compressed with gzip.
does not represent all testcases but what I randomly tried now:
uncompressed : 342549479
gzip -9 : 26053431 0m14.839s
xz -9 -T32: 15135468 0m13.415s (--block-size=10000000)
xz -9e -T32: 12825220 0m38.119s (--block-size=10000000)
xz -1 : 18114936 0m 8.495s
xz -2 : 17632160 0m12.248s
xz -9 : 15490372 3m13.554s
xz -9e : 12606128 18m35.478s
This is not a comparison of compression methods. For that you
can do an online search. This is a patch to support gzipped
exec and core files.
gzip is irrelevant, xz is about twice size or time better by every metric one
Actually, this statement is irrelevant. This is a patch to support the
gzipped files which we have, not files which use some other method which
we do not have.
support for an on-demand block-compression scheme would be significantly
different. Decompressing an xz file by making a copy (as is done for gzip)
would be a simple extension to the current patch.
The on-demand block decompression would bring a new functionality, the whole
file decompression is one command saving convenience function.
I do not plan to implement it, just if you aware of both the xz and block
I'm certainly aware of different compression methods. This patch brings
new functionality to gdb. The patch has a framework which can be extended
to support other methods, if and when someone is interested in implementing it.
Michael Eager firstname.lastname@example.org
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077