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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils