[PATCH] gold: Avoid sharing Plugin_list::iterator

[Alan Modra]

On Fri, Nov 06, 2020 at 03:01:22PM -0800, Cary Coutant wrote:
> > > No, I jumped to the wrong conclusion.  A little more analysis reveals
> > > that the object triggering Plugin_manager::claim_file in ths case is
> > > the LTO output, not one of the command line input objects.  I have no
> > > further worries about plugin data races, and in my opinion HJ's patch
> > > is the correct fix.
> >
> > Thanks for your analysis.  I will check it in next Monday if Cary has no
> > comments.
> 
> I believe this is wrong. In claim_file(), the code already holds a
> lock, so there should be no concurrent access to the iterator. In
> all_symbols_read(), the current task (Plugin_hook) should be the only
> one running at the time. Plugin_manager::current_ needs to be set so
> that when the plugin calls back, we know which plugin is currently
> active. This patch breaks that.
> 
> Thanks for the analysis, which I'll study in more detail. I'm trying
> to figure out what's going on here. There really shouldn't be two
> threads both calling all_symbols_read().

There is only one thread calling all_symbols_read().
all_symbols_read() doesn't hold the lock.  Problem is that another
thread runs claim_file() for the LTO output object, claim_file() sets
Plugin_manager::current_ back to plugins_.begin(), affecting the
all_symbols_read() loop over plugins.

-- 
Alan Modra
Australia Development Lab, IBM