Re: [PATCH] Support gzip compressed exec and core files in gdb

Jan Kratochvil
2015-03-12T11:32:46Z

On Thu, 12 Mar 2015 00:14:21 +0100, Doug Evans wrote:
> On Wed, Mar 11, 2015 at 3:13 PM, Jan Kratochvil
> <jan.kratochvil@redhat.com> wrote:
> > 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
gzip.

Therefore supporting both gzip and xz formats needs two functions / two
libraries / two APIs support in GDB. But that may not be needed:

On Thu, 12 Mar 2015 01:40:20 +0100, Michael Eager wrote:
> gzip is not compressed block-by-block. As far as I can tell, you need to
> decompress starting from the beginning of the file.

I also think so.

Then I do not understand why to support gzip in the first place. One testfile
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

gzip is irrelevant, xz is about twice size or time better by every metric one
can find.

> 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
decompression advantages.

Jan