[Bug gold/19842] LTO build fails to write call address for weak symbol reference

[ccoutant at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19842

--- Comment #24 from Cary Coutant <ccoutant at gmail dot com> ---
> If _bfd_elf_merge_symbol sets *skip, then the new symbol will be ignored.  We
> don't want to do that with a new real weak symbol if we currently have an
> IR-only definition (either strong or weak).

What's your reasoning? If the prevailing definition is in the IR, the
compiler will (theoretically) supply a more-optimized version of that
function than the one in the non-LTO object. Why deliberately favor
the unoptimized version over the optimized version?

(There was some consideration that we should actually favor IR
definitions over non-IR definitions even if the non-IR definition came
first, but we decided that it would be better to continue to honor the
traditional binding order.)

In gold, we track symbols from files claimed by plugins in exactly the
same order that we would if the files were ordinary object files. The
idea is that LTO doesn't have any effect on binding order. That was
one of the fundamental goals of the original LTO plugin design.

Granted, the rules of comdat specifically say that the linker may
choose to keep *any* comdat group with a given key, so ld would be
within its rights to favor a non-IR comdat group over an IR one (but
I'd choose to do it the other way around). Outside of comdat, though,
it doesn't seem right to favor a weak non-IR symbol over a strong IR
one or an earlier weak IR one.

-cary

-- 
You are receiving this mail because:
You are on the CC list for the bug.