From: Tom Tromey <tromey@adacore.com>
To: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
Cc: Tom de Vries <tdevries@suse.de>
Subject: Re: [PATCH v2 5/6] [gdb/symtab] Fix data race on dwarf2_per_cu_data::{m_header_read_in, is_debug_type}
Date: Wed, 02 Aug 2023 13:39:56 -0600 [thread overview]
Message-ID: <87bkfpdyib.fsf@tromey.com> (raw)
In-Reply-To: <20230802095305.3668-6-tdevries@suse.de> (Tom de Vries via Gdb-patches's message of "Wed, 2 Aug 2023 11:53:04 +0200")
>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:
Tom> The race is between:
Tom> - a worker thread writing the index cache, and in the process reading
Tom> dwarf2_per_cu_data::is_debug_type, and
Tom> - the main thread writing to dwarf2_per_cu_data::m_header_read_in.
Tom> The two bitfields dwarf2_per_cu_data::m_header_read_in and
Tom> dwarf2_per_cu_data::is_debug_type share the same bitfield container.
Tom> Fix this by making dwarf2_per_cu_data::m_header_read_in a packed<bool, 1>.
Thanks. This is ok.
Approved-By: Tom Tromey <tom@tromey.com>
FWIW I once tried to clean up the madness surrounding m_header_read_in
and CU header reading in general. Unfortunately I did not succeed... I
don't recall why but I think with DWO the header might have to be from
the DWO. This is all kind of lame, because when doing the initial
cooked index scan, the headers have to be read, and so it seems like the
dwarf2_per_cu_data could be "more read-only" after that.
Tom
next prev parent reply other threads:[~2023-08-02 19:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 9:52 [PATCH v2 0/6] [gdb/symtab] Fix data-races in gdb.base/index-cache.exp Tom de Vries
2023-08-02 9:53 ` [PATCH v2 1/6] [gdb/symtab] Fix data race on index_cache::m_enabled Tom de Vries
2023-08-02 19:29 ` Tom Tromey
2023-08-04 0:08 ` Tom de Vries
2023-08-02 9:53 ` [PATCH v2 2/6] [gdb/symtab] Fix data race on bfd::{cacheable,format} Tom de Vries
2023-08-02 19:32 ` Tom Tromey
2023-08-04 0:09 ` Tom de Vries
2023-08-04 15:57 ` Tom Tromey
2023-08-02 9:53 ` [PATCH v2 3/6] [gdb/symtab] Fix race on dwarf2_per_cu_data::{queued,is_debug_type} Tom de Vries
2023-08-02 19:34 ` [PATCH v2 3/6] [gdb/symtab] Fix race on dwarf2_per_cu_data::{queued, is_debug_type} Tom Tromey
2023-08-02 9:53 ` [PATCH v2 4/6] [gdb/symtab] Fix data race on bfd_last_cache Tom de Vries
2023-08-02 19:37 ` Tom Tromey
2023-08-03 14:04 ` Tom de Vries
2023-08-02 9:53 ` [PATCH v2 5/6] [gdb/symtab] Fix data race on dwarf2_per_cu_data::{m_header_read_in,is_debug_type} Tom de Vries
2023-08-02 19:39 ` Tom Tromey [this message]
2023-08-02 9:53 ` [PATCH v2 6/6] [gdb/testsuite] Extend gdb.base/index-cache.exp Tom de Vries
2023-08-02 19:41 ` Tom Tromey
2023-08-02 19:44 ` [PATCH v2 0/6] [gdb/symtab] Fix data-races in gdb.base/index-cache.exp Tom Tromey
2023-08-04 0:14 ` Tom de Vries
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=87bkfpdyib.fsf@tromey.com \
--to=tromey@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/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).