From: Tom Tromey <tom@tromey.com>
To: Andrew Burgess <aburgess@redhat.com>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 1/2] gdb: move all bfd_cache_close_all calls in gdb_bfd.c
Date: Tue, 31 Oct 2023 12:28:56 -0600 [thread overview]
Message-ID: <87wmv2k5nb.fsf@tromey.com> (raw)
In-Reply-To: <87r0lc1kef.fsf@redhat.com> (Andrew Burgess's message of "Mon, 30 Oct 2023 10:20:40 +0000")
>> However, there is one case where this will change: opening dwo files.
>> Now, the way the background reading is implemented, the worst case here
>> is some inefficiency: the main thread might close all the BFDs, and then
>> the background reader might immediately reopen one.
Andrew> Right now I don't see bfd/cache.c as thread safe, so are you planning to
Andrew> make it thread safe?
Yeah. I sent a series to the binutils list recently.
Andrew> The other option I considered, is that you could add a mechanism to
Andrew> allow BFDs to be opened without going through the BFD cache. In this
Andrew> case, I think your thread safety issues go away, and also, you no longer
Andrew> care about my bfd_cache_close_all() calls. The BFD cache exists to
Andrew> handle systems that only allow a small number of open files (they quote
Andrew> 20 as being a limit on some systems), so avoiding the cache might run
Andrew> into an open FD limit issue ... but I'm not sure if this low limit
Andrew> problem is really a thing on systems that are going to be running
Andrew> multiple threads?
We could definitely do this for the files the DWARF reader opens in the
worker threads.
Not sure if I will do this or not though. Adding an explicit
bfd_cache_close call would also take care of the problem, and I think
the reader only needs the file open from the call to open_dwo_file (in
open_and_init_dwo_file) through mapping the sections -- and they could
be mapped more eagerly in open_and_init_dwo_file.
Andrew> I'd really prefer to avoid relying on folk to remember that they need to
Andrew> call bfd_cache_close_all() in certain places. I think its far too easy
Andrew> to forget, and these are bugs that are only going to crop up once in a
Andrew> while .... A user is running a particular Python extension, and performs
Andrew> a particular action, just at the same time as they recompile their test
Andrew> binary ... and suddenly GDB "misses" that the test executable changed.
Andrew> Bugs like this can be a nightmare to track down.
Yeah.
Tom
next prev parent reply other threads:[~2023-10-31 18:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 15:08 [PATCH 0/2] BFD cache management And Exec file with target: prefix Andrew Burgess
2023-10-25 15:08 ` [PATCH 1/2] gdb: move all bfd_cache_close_all calls in gdb_bfd.c Andrew Burgess
2023-10-26 9:06 ` Lancelot SIX
2023-10-27 8:49 ` Andrew Burgess
2023-10-27 19:30 ` Tom Tromey
2023-10-30 10:20 ` Andrew Burgess
2023-10-31 18:28 ` Tom Tromey [this message]
2023-11-01 10:46 ` Andrew Burgess
2023-11-12 23:38 ` Tom Tromey
2023-10-25 15:08 ` [PATCH 2/2] gdb: fix reopen_exec_file for files with target: prefix Andrew Burgess
2023-10-27 18:39 ` Tom Tromey
2023-10-30 13:41 ` [PATCH 0/2] BFD cache management And Exec file " Andrew Burgess
2023-10-30 13:41 ` [PATCH 1/2] gdb: move all bfd_cache_close_all calls in gdb_bfd.c Andrew Burgess
2023-10-30 13:41 ` [PATCH 2/2] gdb: fix reopen_exec_file for files with target: prefix Andrew Burgess
2023-11-12 23:40 ` [PATCH 0/2] BFD cache management And Exec file " 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=87wmv2k5nb.fsf@tromey.com \
--to=tom@tromey.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