Created attachment 15457 [details] gdb.log I did a run with fedora asahi 39 and -fsanitize=thread, and ran into a issues I haven't seen before in test-case gdb.rust/dwindex.exp: ... SUMMARY: ThreadSanitizer: data race bfd.h:2449 in bfd_get_section_limit_octets SUMMARY: ThreadSanitizer: data race /home/vries/gdb/src/bfd/bfdio.c:514 in bfd_seek ... Rust compiler version: ... $ rustc --version rustc 1.77.0 (aedd173a2 2024-03-17) (Fedora 1.77.0-1.fc39) ...
Both load_auto_scripts_for_objfile and gdb_bfd_map_section call bfd_get_full_section_contents, which might seek/read. The BFD threading approach is that really only one thread can use a BFD at a time, so in this case we probably need the locking in gdb.
Working on this.
https://sourceware.org/pipermail/gdb-patches/2024-October/212454.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ce61f407ac3b509e5b5a16bb79f6848f2de3695f commit ce61f407ac3b509e5b5a16bb79f6848f2de3695f Author: Tom Tromey <tom@tromey.com> Date: Thu Oct 17 17:16:54 2024 -0600 Add locking when reading BFD sections This adds some per-BFD locking to gdb_bfd_map_section and gdb_bfd_get_full_section_contents. It turned out that the background DWARF reader could race with the auto-load code, because the reader might try to mmap a section when the main thread was trying to read in .debug_gdb_scripts. The current BFD threading model is that only BFD globals will be locked, so any multi-threaded use of a BFD has to be handled specially by the application. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31626 Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Fixed.