This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Support gzip compressed exec and core files in gdb
- From: Alan Modra <amodra at gmail dot com>
- To: Michael Eager <eager at eagerm dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, binutils <binutils at sourceware dot org>
- Date: Thu, 12 Mar 2015 13:20:49 +1030
- Subject: Re: [PATCH] Support gzip compressed exec and core files in gdb
- Authentication-results: sourceware.org; auth=none
- References: <54FF77D6 dot 7010400 at eagerm dot com> <20150311081454 dot GK11451 at bubble dot grove dot modra dot org> <5500579E dot 50706 at eagerm dot com> <20150312000822 dot GA8533 at bubble dot grove dot modra dot org> <5500E1A8 dot 6030101 at eagerm dot com>
On Wed, Mar 11, 2015 at 05:45:28PM -0700, Michael Eager wrote:
> 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.
It looks to me that exec_close() calls bfd_close(). You won't be able
to do anything with the bfd after bfd_close(), so I think your
analysis is faulty and very much doubt your statement that "GDB closes
the exec file, then uses BFD..".
--
Alan Modra
Australia Development Lab, IBM