From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115789 invoked by alias); 12 Mar 2015 16:13:11 -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 115769 invoked by uid 89); 12 Mar 2015 16:13:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_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 16:13:08 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2CGD6Sn007301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 12 Mar 2015 12:13:07 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2CGCuX6004982; Thu, 12 Mar 2015 12:12:59 -0400 Message-ID: <5501BB08.90503@redhat.com> Date: Thu, 12 Mar 2015 16:13:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michael Eager , Jan Kratochvil CC: "gdb-patches@sourceware.org" , binutils Subject: Re: [PATCH] Support gzip compressed exec and core files in gdb References: <54FF77D6.7010400@eagerm.com> <20150311221329.GB11980@host1.jankratochvil.net> <5500E074.6070002@eagerm.com> <55016D6F.4010104@redhat.com> <5501B1EB.5010806@eagerm.com> In-Reply-To: <5501B1EB.5010806@eagerm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00345.txt.bz2 On 03/12/2015 03:34 PM, Michael Eager wrote: > On 03/12/15 03:41, Pedro Alves wrote: > >> Waiting for GDB to decompress that once is already painful. Waiting for it >> multiple times likely results in cursing and swearing at gdb's slow start >> up. Smart users will realize that and end up decompressing the file manually >> outside gdb, just once, anyway, thus saving time. >> >> We could "fix" the "multiple times" issue by adding even more smarts, >> based on an already-decompressed-files cache or some such. Though of >> course, more smarts, more code to maintain. > > I had considered adding a command or command line option to specify > the name of the uncompress file, so that it could be reused. What's the point then? If you need to do that, then you alread lost all the convenience. Just type "gunzip core.gz && gdb core" instead of "gdb -tmp-core /tmp/core core.gz". So I think my point still stands, and IMO, it's a crucial point. > >> I agree with Jan -- The real convenience would be being able to skip the >> long whole-file decompression step altogether, with an on-demand >> block-decompress scheme, because gdb in reality doesn't need to touch >> most of the vast majority of the core dump's contents. That would >> be a solution that I'd be happy to see implemented. > > That's a solution to a different problem. I don't think it is. What's the real problem you're solving? >> If we're just decompressing to /tmp, then we also need to >> compare the benefits of a built-in solution against having users >> do the same with a user-provided gdb command implemented in one >> of gdb's extensions languages (python, scheme), e.g., a command >> that adds a "decompress-core" command that does the same: >> decompresses whatever compression format, and loads the result >> with "core /tmp/FILE". > > This requires that users manually decompress files, and makes it > impossible to put the compressed file name on the command line. No it doesn't: there's '-ex' to run commands on the command line: gdb -ex "decompress-and-load-core foo.gz" > > It also looks to me like a wart and kludge, rather than having > GDB automatically identify the compression method and do the > operation transparently for the user. What I'm saying is that it seems to me that you're doing automatically in GDB, it can be done automatically in a script. A gdb command implemented in python can of course also identify the compression method and support a multiple number of compression formats, by just calling the appropriate decompression tool. As I said, I won't strongly object, though I still don't see the compelling use case that warrants doing this in GDB. I do envision ahead the usability problems and support requests this will lead to. > >> IMO, whatever the solution, if built in, this is best implemented >> in BFD, so that objdump can dump the same files gdb can. > > I took that approach initially. But GDB finds and opens files, > not BFD. Moving what GDB is doing into BFD, where it should have > been in the first place (IMO), seemed more problematic. If there's problems, let's fix them. From Alan's response, the problem you mention doesn't really exist in the form you described. Thanks, Pedro Alves