This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Support gzip compressed exec and core files in gdb
- From: Michael Eager <eager at eagerm dot com>
- To: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, binutils <binutils at sourceware dot org>, Alan Modra <amodra at gmail dot com>
- Date: Thu, 12 Mar 2015 09:14:12 -0700
- 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> <20150312025049 dot GB8533 at bubble dot grove dot modra dot org>
On 03/11/15 19:50, Alan Modra wrote:
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
Really? I think it quite unclean if gdb expects BFD to reopen a file
that gdb has closed!
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..".
The file opened in exec_file_attach() is closed in bfd_cache_close_all(),
before the function returns, not in the call to exec_close(). The bfd
is not deleted.
Later, in bfd_get_section_contents(), while sniffing the OSABI, GDB calls
bfd_seek() to do a seek on the same bfd. This notices that bfd->iostream
is zero and re-opens the file.
Michael Eager email@example.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077