[PATCH v2] gold: ensure file_counts_lock is initialized before using

[Cary Coutant]

> > May I ask you, is it going to fix the following issue:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=26200
> > ?
> >
>
> It's not directly related. I think H. J. Lu's patch on Bugzilla is
> correct: I checked just now with -fsanitize=thread and can see two
> threads concurrently accessing the current_ iterator in
> Plugin_manager::all_symbols_read() and Plugin_manager::claim_file(). But
> without my patch it would still have segfaulted, just in a different
> place.

The threading bug just fixed has only been in the tree for a few
months, and is unrelated to PR 26200.

HJ's patch is not correct. I'm trying to understand how this can
happen -- in claim_file(), the code already holds a lock to prevent
concurrent access; in all_symbols_read(), the code should be running
single-threaded at that point. Whatever the bug, it's more subtle than
that.

The current_ iterator needs to be non-local, since any callbacks from
the plugin need to be able to reference the current plugin. HJ's patch
breaks that. I could perhaps make that a thread-local variable or
embed it into the handle passed to the plugin, but it shouldn't be
necessary, as it's supposed to be protected already. That it isn't
means there's a bug somewhere else.

-cary