From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64498 invoked by alias); 12 Mar 2015 16:58:07 -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 64473 invoked by uid 89); 12 Mar 2015 16:58:06 -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-a48.g.dreamhost.com Received: from sub5.mail.dreamhost.com (HELO homiemail-a48.g.dreamhost.com) (208.113.200.129) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Mar 2015 16:58:04 +0000 Received: from homiemail-a48.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a48.g.dreamhost.com (Postfix) with ESMTP id 58D9E4F805B; Thu, 12 Mar 2015 09:58:03 -0700 (PDT) Received: from redwood.eagercon.com (c-24-7-16-38.hsd1.ca.comcast.net [24.7.16.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eager@eagerm.com) by homiemail-a48.g.dreamhost.com (Postfix) with ESMTPSA id 30CBE4F806A; Thu, 12 Mar 2015 09:58:03 -0700 (PDT) Message-ID: <5501C59A.1070405@eagerm.com> Date: Thu, 12 Mar 2015 16:58: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: Pedro Alves , 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> <5501BB08.90503@redhat.com> In-Reply-To: <5501BB08.90503@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00351.txt.bz2 On 03/12/15 09:12, Pedro Alves wrote: > 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? Lots of users, most who are not very conversant with gdb, lots of compressed exec and core files, all compressed with gzip. The goal is to make using compressed files simple and transparent, without users having to enter additional commands. A wonderful patch supporting xz compressed files with an on-demand block-decompress scheme would be a great solution for some other use case, one which seems hypothetical at the moment. >>> 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" As I said, this requires users to know whether an exec or core is compressed and manually enter a command to uncompress it. >> 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. We have many wrappers around gdb, some of which handle compressed files, some of which don't. They are all different and problematic to debug and maintain. Putting support for compressed files into gdb means that it simply works, and users don't have to remember which wrapper accepts compressed files and which don't. > 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. I misspoke/misremembered. It isn't exec_close() which closes the file, it is bfd_cache_close_all(). The bfd is not closed, only the file. While BFD does most of the file operations, there isn't a clear functional boundary between GDB file operations and BFD file operations. Allowing an opened fd to be passed into BFD makes doing the decompression in BFD problematic, since BFD doesn't know where the opened file was found, and the decompress libraries (at least gzopen()) expects a path, not an opened fd. BFD wouldn't be know how the fd was opened so that it could use the same flags to open the uncompressed file. Fixing the problem would mean eliminating functions in BFD which accepted an open fd and replacing calls to these functions with modified versions of bfd_open() which accepted additional flags or did whatever other operations the caller did when opening the files. GDB opens files a number of places, such as in exec_file_attach() using openp() which searches the path for the file. This would have to be migrated into BFD. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077