[lto] Fix symlookup in archives vs shared

[Michael Matz]

Hello,

On Tue, 8 Apr 2025, Jeff Law wrote:

> > when a shared library defines 'foo@@FOO' (default version),
> > a static archive defines 'foo', the shared lib comes in front
> > of the archive and under effect of --as-needed, and the requesting
> > object file uses LTO, then the link editor was wrongly including
> > the definition from the static archive.  It must use the one
> > from the shared lib, like in the non-LTO or the --no-as-needed case.
> > See the added testcase that would wrongly print "FAIL" before
> > this patch.
> > 
> > The problem stems from several connected problems:
> > (1) only the decorated symbol was entered into first_hash (the hash
> >      table designed to handle definition order in the pre-LTO-plugin
> >      phase of the symbol table walks)
> > (2) in the archive symbol walk only the undecorated name would be
> >      looked up in first_hash (and hence not found due to (1))
> > (3) in the archive symbol walk first_hash would only be consulted
> >      when the linker hash table had a defined symbol.  In pre-LTO
> >      phase shared lib symbols aren't entered into the linker symbol
> >      table.
> > 
> > So: add also the undecorated name into first_hash when it stems from
> > a default version and consult first_hash in the archive walker also
> > for currently undefined symbols.  If it has an entry which doesn't
> > point to the archive, then it comes from an earlier library (shared or
> > static), and so _this_ archive won't provide the definition.
> 
> This caused a number of the embedded targets to regress in their 
> testsuites, typically due to an undefined symbol such as __muldf3 that 
> should have been provided by libgcc.

Hmpf, it seems nothing in the binutils testsuite catched anything like 
that at all.  I've ran it on a multitude of targets, including ...

> Just picking one, ft32-elf:

... this.

> But this was pretty pervasive across the crosses.

Hopefully the patch of H.J. fixed that.


Ciao,
Michael.