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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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