Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Eager <eager@eagerm.com>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	 binutils <binutils@sourceware.org>
Subject: Re: [PATCH] Support gzip compressed exec and core files in gdb
Date: Thu, 12 Mar 2015 00:45:00 -0000	[thread overview]
Message-ID: <5500E1A8.6030101@eagerm.com> (raw)
In-Reply-To: <20150312000822.GA8533@bubble.grove.modra.org>

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


  reply	other threads:[~2015-03-12  0:45 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 23:01 Michael Eager
2015-03-11  2:37 ` Mike Frysinger
2015-03-11 15:00   ` Michael Eager
2015-03-11  8:15 ` Alan Modra
2015-03-11 14:57   ` Michael Eager
2015-03-12  0:08     ` Alan Modra
2015-03-12  0:45       ` Michael Eager [this message]
2015-03-12  2:51         ` Alan Modra
2015-03-12 16:14           ` Michael Eager
2015-03-13  0:13             ` Alan Modra
2015-03-11 10:07 ` Gary Benson
2015-03-11 14:58   ` Michael Eager
2015-03-11 17:42     ` Gary Benson
2015-03-11 18:10       ` Doug Evans
2015-03-11 18:32         ` Gary Benson
2015-03-11 18:56           ` Doug Evans
2015-03-11 16:15 ` Eli Zaretskii
2015-03-11 19:55   ` Michael Eager
2015-03-11 20:18     ` Mike Frysinger
2015-03-11 20:24     ` Eli Zaretskii
2015-03-12 21:17       ` Sergio Durigan Junior
2015-03-13  6:04         ` Eli Zaretskii
2015-03-11 18:24 ` Cary Coutant
2015-03-11 20:12   ` Michael Eager
2015-03-11 20:19     ` Doug Evans
2015-03-11 22:13 ` Jan Kratochvil
2015-03-11 23:14   ` Doug Evans
2015-03-12 11:32     ` Jan Kratochvil
2015-03-12 15:24       ` Michael Eager
2015-03-12  0:40   ` Michael Eager
2015-03-12 11:31     ` Pedro Alves
2015-03-12 15:34       ` Michael Eager
2015-03-12 16:13         ` Pedro Alves
2015-03-12 16:58           ` Michael Eager
2015-03-12 17:11             ` Jan Kratochvil
2015-03-12 17:37               ` Michael Eager
2015-03-12 17:48                 ` Jan Kratochvil
2015-03-13  6:25               ` Ed Maste
2015-03-19  0:58 ` Michael Eager
2015-03-19  3:45   ` Eli Zaretskii
2015-03-20 22:16   ` Mike Frysinger
2015-03-27 15:26     ` Michael Eager
2015-03-28  4:49       ` Mike Frysinger
2015-03-28 16:56       ` Michael Eager
2015-04-01 12:41         ` Pedro Alves
2015-04-01 18:52           ` Michael Eager
2015-04-01 19:10             ` Pedro Alves
2015-05-01 14:40 ` Michael Eager
2015-05-01 17:53   ` Eli Zaretskii
2015-05-01 22:03     ` Michael Eager
2015-05-04  7:50       ` Mike Frysinger
2015-06-15 15:14         ` Michael Eager

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5500E1A8.6030101@eagerm.com \
    --to=eager@eagerm.com \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox