From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114087 invoked by alias); 12 Mar 2015 11:32:46 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 114010 invoked by uid 89); 12 Mar 2015 11:32:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 12 Mar 2015 11:32:44 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2C4sfhR021613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 12 Mar 2015 00:54:41 -0400 Received: from host1.jankratochvil.net ([10.40.204.20]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2C4sbXm002975 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 00:54:40 -0400 Date: Thu, 12 Mar 2015 11:32:00 -0000 From: Jan Kratochvil To: Doug Evans , Michael Eager Cc: "gdb-patches@sourceware.org" , binutils Subject: Re: [PATCH] Support gzip compressed exec and core files in gdb Message-ID: <20150312045436.GA31225@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5500E074.6070002@eagerm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00335.txt.bz2 On Thu, 12 Mar 2015 00:14:21 +0100, Doug Evans wrote: > On Wed, Mar 11, 2015 at 3:13 PM, Jan Kratochvil > 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