[Bug lto/82575] [8 Regression] lto debugobj references __gnu_lto_slim, ld test liblto-17 fails

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82575

--- Comment #5 from Alan Modra <amodra at gmail dot com> ---
> --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
> Hmm, but those symbols will prevail, enlarging the final symbol table?
> Or are weak + hidden symbols removed even for shared libaries?

Well, they are still undefined.  Being hidden they won't become
dynamic unless your linker is broken.

> IIRC the Solaris linker didn't like to interpret "unused" (aka unreferenced)

From pr81968 it seems the symbol related complaint was just that the
linker warned on seeing a global symbol without name, which is kind of
reasonable given that a global symbol's linkage is via name.

> UNDEF globals as irrelevant, complaining about missing symbols later.  GNU
> ld simply discards those in the partial link we perform over all debug
> objects.

Yes, it's possible that other linkers might not remove the undefined
symbols from .symtab, which would leave nm and other binutils broken.
If that happens, I suppose we could edit .strtab to change the name of
__gnu_lto_slim, or bump st_name by one.

Changing global syms to local doesn't work since the locals must be
first in .symtab.  Using STT_FILE would work with GNU ld, but it's
anybody's guess how global STT_FILE symbols are handled in other
linkers.