Re: [PATCH] Support gzip compressed exec and core files in gdb

[Alan Modra <amodra@gmail.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