This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/82575] [8 Regression] lto debugobj references __gnu_lto_slim, ld test liblto-17 fails
- From: "amodra at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 19 Oct 2017 13:26:09 +0000
- Subject: [Bug lto/82575] [8 Regression] lto debugobj references __gnu_lto_slim, ld test liblto-17 fails
- Auto-submitted: auto-generated
- References: <bug-82575-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82575
--- Comment #7 from Alan Modra <amodra at gmail dot com> ---
> --- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
> OK. I suppose they are properly prevailed by any global symbol of the same name
> as well? Like a weak definition with default visibility? Or is there the chance
> of linker diagnostics about 'mismatches'?
Yes, I think they should be OK. The ELF gABI says of hidden symbols:
"A hidden symbol contained in a relocatable object must be either removed or
converted to STB_LOCAL binding by the link-editor when the relocatable object
is included in an executable file or shared object."
With luck, linkers will choose the first option.
Also:
"First, all of the non-default visibility attributes, when applied to a symbol
reference, imply that a definition to satisfy that reference must be provided
within the current executable or shared object. If such a symbol reference has
no definition within the component being linked, then the reference must have
STB_WEAK binding and is resolved to zero."
Which is why I made the symbol weak as well as hidden. Otherwise
there may well have been a warning.