From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80894 invoked by alias); 12 Mar 2015 15:24:31 -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 80872 invoked by uid 89); 12 Mar 2015 15:24:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: homiemail-a68.g.dreamhost.com Received: from sub5.mail.dreamhost.com (HELO homiemail-a68.g.dreamhost.com) (208.113.200.129) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Mar 2015 15:24:29 +0000 Received: from homiemail-a68.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a68.g.dreamhost.com (Postfix) with ESMTP id E8AA940113760; Thu, 12 Mar 2015 08:24:27 -0700 (PDT) Received: from redwood.eagercon.com (c-24-7-16-38.hsd1.ca.comcast.net [24.7.16.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eager@eagerm.com) by homiemail-a68.g.dreamhost.com (Postfix) with ESMTPSA id BDA9040113745; Thu, 12 Mar 2015 08:24:27 -0700 (PDT) Message-ID: <5501AFAB.2000106@eagerm.com> Date: Thu, 12 Mar 2015 15:24:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jan Kratochvil , Doug Evans CC: "gdb-patches@sourceware.org" , binutils Subject: Re: [PATCH] Support gzip compressed exec and core files in gdb References: <20150312045436.GA31225@host1.jankratochvil.net> In-Reply-To: <20150312045436.GA31225@host1.jankratochvil.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00340.txt.bz2 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 >> 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