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

[Michael Eager]

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

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.

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

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
> can find.

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

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	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077