From: Tom Tromey <tromey@adacore.com>
To: Andrew Burgess <aburgess@redhat.com>
Cc: Tom Tromey <tromey@adacore.com>,
Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 9/9] gdb: use reopen_exec_file from reread_symbols
Date: Thu, 28 Sep 2023 12:15:18 -0600 [thread overview]
Message-ID: <87msx62mh5.fsf@tromey.com> (raw)
In-Reply-To: <877coawcd9.fsf@redhat.com> (Andrew Burgess's message of "Thu, 28 Sep 2023 16:23:14 +0100")
>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
Andrew> I didn't fully understand all the discussion w.r.t. gnulib stat vs
Andrew> system stat, but I'm hoping the change above, which is less that your
Andrew> originally proposed full change, might be mergable.
FTR (and IIUC) the issue is that gnulib's stat yields different times on
Windows hosts, because it tries to handle the timezone -- on Unix, stat
reports in UTC, but on Windows it may report in local time.
The result is that BFD will report times that are offset from the times
reported by gnulib.
gnulib doesn't provide a way to change this behavior, so one proposal in
the thread was to hack gnulib.
>> I don't think gdb has a very clear idea of when bfd_cache_close_all
>> ought to be called.
Andrew> I agree this stuff doesn't seem well defined at all, but I don't think I
Andrew> made anything particularly worse in this respect, so I'm leaving that as
Andrew> a problem for the future.
One thing I wonder is whether bfd_cache_close_all is even needed.
gdbserver doesn't do this and AFAIK, gdb just keeps all those remote fds
open.
Maybe we're missing some testing scenario, though, like gdbserver
extended-remote with "gdb --write".
Tom
next prev parent reply other threads:[~2023-09-28 18:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-16 10:18 [PATCH 0/9] Add executable_changed event to Python API Andrew Burgess
2023-09-16 10:18 ` [PATCH 1/9] gdb/doc: extend the description for Progspace.filename Andrew Burgess
2023-09-16 10:53 ` Eli Zaretskii
2023-09-16 10:18 ` [PATCH 2/9] gdb/python: new Progspace.symbol_file attribute Andrew Burgess
2023-09-16 10:56 ` Eli Zaretskii
2023-09-16 10:18 ` [PATCH 3/9] gdb/python: new Progspace.executable_filename attribute Andrew Burgess
2023-09-16 10:55 ` Eli Zaretskii
2023-09-16 10:18 ` [PATCH 4/9] gdb: remove one user of the executable changed observer Andrew Burgess
2023-09-16 10:18 ` [PATCH 5/9] gdb: remove final user of the executable_changed observer Andrew Burgess
2023-09-16 10:18 ` [PATCH 6/9] gdb: remove unnecessary notification of " Andrew Burgess
2023-09-16 10:18 ` [PATCH 7/9] gdb: pass more arguments to the " Andrew Burgess
2023-09-16 10:18 ` [PATCH 8/9] gdb/python: make the executable_changed event available from Python Andrew Burgess
2023-09-16 11:03 ` Eli Zaretskii
2023-09-28 14:35 ` Andrew Burgess
2023-09-16 10:18 ` [PATCH 9/9] gdb: use reopen_exec_file from reread_symbols Andrew Burgess
2023-09-19 14:08 ` Tom Tromey
2023-09-28 15:23 ` Andrew Burgess
2023-09-28 18:15 ` Tom Tromey [this message]
2023-09-29 10:17 ` Andrew Burgess
2023-09-29 15:18 ` Eli Zaretskii
2023-10-02 14:16 ` Tom Tromey
2023-09-29 14:42 ` Eli Zaretskii
2023-10-02 14:02 ` Tom Tromey
2023-10-02 16:19 ` Eli Zaretskii
2023-09-19 14:09 ` [PATCH 0/9] Add executable_changed event to Python API Tom Tromey
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=87msx62mh5.fsf@tromey.com \
--to=tromey@adacore.com \
--cc=aburgess@redhat.com \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).