[lto] Fix symlookup in archives vs shared

[Sam James]

Michael Matz <matz@suse.de> writes:

> 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.

[For completeness to tie the ML to the bug, H.J. filed
https://sourceware.org/PR32854 for this afterwards.]