[v2,0/6,gdb/symtab] Fix data-races in gdb.base/index-cache.exp

  When building gdb with -fsanitize=thread, we run into a data race in
gdb.base/index-cache.exp.

Fixing this leads us to another, and so on, so each patch addresses one
particular data race, with the exception of the last patch, which extends
the test-case a bit.

The last patch, when applied without the series runs into a segfault with
target board native-extended-gdbserver, filed as PR symtab/30712, but that
seems to be fixed by a previous commit in this series.  This is the reason for
which the patch is part of this series.

The first two patches implement the approach mentioned in PR30392 comment 2:
...
The reader probably should capture the necessarily globals
on the main thread and stash them until the index has been
written.
...

The 3rd patch cannot be fixed with this approach, so it uses the packed<bool, 1>
approach:
...
-  unsigned int queued : 1;
+  packed<bool, 1> queued;
...

There's one more patch like that, I checked using pahole that the struct size
is not increased.

I spent some time convincing myself that the data races on disjoint bitfields
are not benign.  I started with reading [1], and got convinced by
"2.5 Disjoint bit manipulation" in [2].  Also [3] looked interesting, but
haven't read it in full.

Tested on x86_64-linux, with and without -fsanitize=thread.

PR symtab/30392
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392

References:
[1] https://hacks.mozilla.org/2021/04/eliminating-data-races-in-firefox-a-technical-report/
[2] https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf
[3] https://bartoszmilewski.com/2020/08/11/benign-data-races-considered-harmful/

Tom de Vries (6):
  [gdb/symtab] Fix data race on index_cache::m_enabled
  [gdb/symtab] Fix data race on bfd::{cacheable,format}
  [gdb/symtab] Fix race on dwarf2_per_cu_data::{queued,is_debug_type}
  [gdb/symtab] Fix data race on bfd_last_cache
  [gdb/symtab] Fix data race on
    dwarf2_per_cu_data::{m_header_read_in,is_debug_type}
  [gdb/testsuite] Extend gdb.base/index-cache.exp

 gdb/dwarf2/cooked-index.c              | 19 ++++++++---
 gdb/dwarf2/cooked-index.h              |  3 +-
 gdb/dwarf2/index-cache.c               | 46 ++++++++++++++++++++------
 gdb/dwarf2/index-cache.h               | 25 +++++++++++++-
 gdb/dwarf2/read.c                      |  8 ++---
 gdb/dwarf2/read.h                      | 26 +++++++--------
 gdb/testsuite/gdb.base/index-cache-2.c | 24 ++++++++++++++
 gdb/testsuite/gdb.base/index-cache.c   |  6 ++--
 gdb/testsuite/gdb.base/index-cache.exp | 22 ++++++++++--
 9 files changed, 141 insertions(+), 38 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/index-cache-2.c


base-commit: 69c37f53e20dc3e0b3c179b511ff786db6ae114e
  

>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:

Thanks for this series.  I read through it and sent a few notes.

Tom> There's one more patch like that, I checked using pahole that the struct size
Tom> is not increased.

"ptype/o" is basically pahole FWIW.

I tend to think that in most cases, the size of objects doesn't really
matter.  I mean, obviously we don't want to bloat them unnecessarily,
but for something like this, I just wouldn't worry much... and if we did
care there's probably some other way we could shrink them than worrying
about packing.

In the olden days pretty much the only thing really worth worrying about
was partial symbols.  Now I guess it would be cooked_index_entry.

Tom
  

On 8/2/23 21:44, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Thanks for this series.  I read through it and sent a few notes.
> 
> Tom> There's one more patch like that, I checked using pahole that the struct size
> Tom> is not increased.
> 
> "ptype/o" is basically pahole FWIW.
> 
> I tend to think that in most cases, the size of objects doesn't really
> matter.  I mean, obviously we don't want to bloat them unnecessarily,
> but for something like this, I just wouldn't worry much... and if we did
> care there's probably some other way we could shrink them than worrying
> about packing.
> 
> In the olden days pretty much the only thing really worth worrying about
> was partial symbols.  Now I guess it would be cooked_index_entry.

Ack.

I've submitted a v3, following up on comments and dropping the patch 
that's no longer required.

I'll commit tomorrow unless there are further comments.

Thanks,
- Tom