[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 #30 from Cary Coutant <ccoutant at gmail dot com> ---
> The LTO symbols are of course not the
> final symbols but only tentative definitions.  When merging symbols, if we
> see a weak symbol in a non-LTO object after seeing the tentative definition
> from an LTO object, we want the non-LTO symbol to win.  The LTO object might
> not actually provide the symbol after recompilation.

As we've seen, that's unfortunately true, but I think it's a bug in GCC. If the
linker gives a symbol resolution of PREVAILING_DEF (which means the prevailing
definition is in the IR object, and there are references to the symbol from
non-IR objects), the compiler is *required* to provide a definition. From the
whopr/driver wiki page:

"Any symbol marked PREVAILING_DEF must be defined in one object file added to
the link after WPA is done, or an undefined symbol error will result. Any
symbol marked PREVAILING_DEF_IRONLY may be left undefined (provided all
references to the symbol have been removed), and the linker will not issue an
error. Any symbol marked PREVAILING_DEF_IRONLY_EXP may be left undefined if the
compiler determines that any dynamically-loaded shared object that would
reference the symbol will provide its own definition of the symbol (e.g., the
symbol is always defined in a COMDAT group)."

We really do want the LTO symbol to win. It will be better optimized.

-cary

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