From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6385 invoked by alias); 12 Mar 2015 00:45:32 -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 6351 invoked by uid 89); 12 Mar 2015 00:45:31 -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-a94.g.dreamhost.com Received: from sub5.mail.dreamhost.com (HELO homiemail-a94.g.dreamhost.com) (208.113.200.129) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Mar 2015 00:45:30 +0000 Received: from homiemail-a94.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a94.g.dreamhost.com (Postfix) with ESMTP id 0A6C138A059; Wed, 11 Mar 2015 17:45:29 -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-a94.g.dreamhost.com (Postfix) with ESMTPSA id C36CC38A058; Wed, 11 Mar 2015 17:45:28 -0700 (PDT) Message-ID: <5500E1A8.6030101@eagerm.com> Date: Thu, 12 Mar 2015 00:45: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: "gdb-patches@sourceware.org" , binutils Subject: Re: [PATCH] Support gzip compressed exec and core files in gdb References: <54FF77D6.7010400@eagerm.com> <20150311081454.GK11451@bubble.grove.modra.org> <5500579E.50706@eagerm.com> <20150312000822.GA8533@bubble.grove.modra.org> In-Reply-To: <20150312000822.GA8533@bubble.grove.modra.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00331.txt.bz2 On 03/11/15 17:08, Alan Modra wrote: > On Wed, Mar 11, 2015 at 07:56:30AM -0700, Michael Eager wrote: >> On 03/11/15 01:14, Alan Modra wrote: >>> On Tue, Mar 10, 2015 at 04:01:42PM -0700, Michael Eager wrote: >>>> This operation cannot be done completely by BFD because BFD allows an opened >>>> file to be passed to it for processing. GDB uses this functionality. >>> >>> I'd prefer you do this entirely outside of BFD, without adding another >>> field to struct bfd. I think that can be done by simply clearing >>> abfd->cacheable on files you uncompress. This prevents BFD from >>> closing the file, so you won't need to open it again. >> >> GDB closes the exec file, then uses BFD to seek (I think when reading >> syms). BFD then re-opens the file, so it needs the name of the >> uncompressed file. > > Really? I think it quite unclean if gdb expects BFD to reopen a file > that gdb has closed! Agreed. GDB doesn't expect BFD to reopen the file, per se. But it does a seek on an exec file (IIRC, while reading symbols) which it previously closed and when BFD notices that the file is closed, it opens it. I don't think that it is feasible to remove calls to exec_close() so this doesn't happen. There's overlapping code between BFD and GDB. It would be much cleaner if GDB let BFD do everything with files, and BFD had support for opening files with additional flags like O_CLOEXEC. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077