Re: [PATCH v2 2/2] [gdb/symtab] Fix data race in try_open_dwop_file

[Tom de Vries <tdevries@suse.de>]

On 5/27/26 10:48 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> 
> Tom> AFAIU, bfd_check_format does locking, but it's only used to [1]:
> Tom> ...
> Tom> lock the internal global data structures of BFD (like its global cache
> Tom> or some global counter), but not data in individual `bfd *`instances.
> Tom> ...
> 
> Tom> So while it does do locking, it's not sufficient.
> 
> How so?
> 
> I mean, since it's a recursive lock, it's not like locking it some more
> can cause a problem.  But at the same time I don't think it adds any
> more protection.

Well, the race is on fields of individual "bfd *" instances.

More specifically, this write in bfd_cache_delete:
...
   abfd->last_io = bfd_io_force;
...
vs one of these reads (abfd->format or abfd->direction) in:
...
   if (!bfd_read_p (abfd)
       || (unsigned int) abfd->format >= (unsigned int) bfd_type_end)
...

As pointed out by Simon, the bfd code doesn't provide any locking for that.

So the gdb wrappers provide the additional locking needed.  AFAIU, this 
is not specific to these wrappers, all gdb_bfd wrapper are needed for 
the same reason.

Thanks,
- Tom