This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]