From: Tom Tromey <tom@tromey.com>
To: binutils@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [PATCH 1/3] Make several more BFD globals thread-local
Date: Mon, 29 Jan 2024 18:03:31 -0700 [thread overview]
Message-ID: <20240130010540.1754740-2-tom@tromey.com> (raw)
In-Reply-To: <20240130010540.1754740-1-tom@tromey.com>
Among other things, PR gdb/31264 points out a race in bfd_check_format
-- it sets the error handler, which is a global.
Looking into this a bit more, I found several other possible races:
the "in_check_format" static local variable in
bfd_check_format_matches, and the contents of per_xvec_warn.
This patch makes all of these thread-local.
I don't actually think this is the best way to approach this.
"in_check_format" and the per-xvec warnings could be done by setting a
flag on the BFD, avoiding globals entirely. I can do that if you
want; I just wasn't sure if that is desirable or not.
Note that this bug also points out a race between bfd_cache_close_all
and bfd_check_format; I am not sure yet how this should be handled.
bfd/ChangeLog
2024-01-29 Tom Tromey <tom@tromey.com>
PR gdb/31264
* targets.c (per_xvec_warn): Now thread-local.
* format.c (bfd_check_format_matches): Mark "in_check_format" as
thread-local.
* bfd.c (_bfd_error_internal, error_handler_bfd): Now
thread-local.
---
bfd/ChangeLog | 9 +++++++++
bfd/bfd.c | 4 ++--
bfd/format.c | 2 +-
bfd/targets.c | 4 ++--
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/bfd/bfd.c b/bfd/bfd.c
index 0776145af52..5619799e403 100644
--- a/bfd/bfd.c
+++ b/bfd/bfd.c
@@ -1504,7 +1504,7 @@ err_sprintf (void *stream, const char *fmt, ...)
/* Communicate the bfd processed by bfd_check_format_matches to the
error handling function error_handler_sprintf. */
-static bfd *error_handler_bfd;
+static TLS bfd *error_handler_bfd;
/* An error handler that prints to a string, then dups that string to
a per-xvec cache. */
@@ -1538,7 +1538,7 @@ error_handler_sprintf (const char *fmt, va_list ap)
function pointer permits a program linked against BFD to intercept
the messages and deal with them itself. */
-static bfd_error_handler_type _bfd_error_internal = error_handler_fprintf;
+static TLS bfd_error_handler_type _bfd_error_internal = error_handler_fprintf;
/*
FUNCTION
diff --git a/bfd/format.c b/bfd/format.c
index 47c3e9ba35a..ec37441904c 100644
--- a/bfd/format.c
+++ b/bfd/format.c
@@ -321,7 +321,7 @@ bfd_check_format_matches (bfd *abfd, bfd_format format, char ***matching)
struct bfd_preserve preserve, preserve_match;
bfd_cleanup cleanup = NULL;
bfd_error_handler_type orig_error_handler;
- static int in_check_format;
+ static TLS int in_check_format;
if (matching != NULL)
*matching = NULL;
diff --git a/bfd/targets.c b/bfd/targets.c
index 3addf2fe373..ca2a2039217 100644
--- a/bfd/targets.c
+++ b/bfd/targets.c
@@ -1458,8 +1458,8 @@ const bfd_target *const *const bfd_associated_vector = _bfd_associated_vector;
const size_t _bfd_target_vector_entries = ARRAY_SIZE (_bfd_target_vector);
/* A place to stash a warning from _bfd_check_format. */
-static struct per_xvec_message *per_xvec_warn[ARRAY_SIZE (_bfd_target_vector)
- + 1];
+static TLS struct per_xvec_message *per_xvec_warn[ARRAY_SIZE (_bfd_target_vector)
+ + 1];
\f
/* This array maps configuration triplets onto BFD vectors. */
--
2.43.0
next prev parent reply other threads:[~2024-01-30 1:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 1:03 [PATCH 0/3] Fix some error-printing issues Tom Tromey
2024-01-30 1:03 ` Tom Tromey [this message]
2024-02-12 15:28 ` [PATCH 1/3] Make several more BFD globals thread-local Nick Clifton
2024-02-12 23:52 ` Tom Tromey
2024-02-13 0:35 ` Tom Tromey
2024-02-13 1:20 ` Tom Tromey
2024-03-09 1:12 ` Tom Tromey
2024-03-09 4:11 ` Alan Modra
2024-03-09 10:31 ` Alan Modra
2024-03-15 0:12 ` Tom Tromey
2024-03-19 20:17 ` Tom Tromey
2024-03-15 1:15 ` Tom Tromey
2024-01-30 1:03 ` [PATCH 2/3] Do not call fputc from _bfd_doprnt Tom Tromey
2024-02-12 15:04 ` Nick Clifton
2024-01-30 1:03 ` [PATCH 3/3] Introduce bfd_print_error function Tom Tromey
2024-02-12 15:04 ` Nick Clifton
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=20240130010540.1754740-2-tom@tromey.com \
--to=tom@tromey.com \
--cc=binutils@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).