[Bug lto/105933] LTO ltrans object files does not have proper st_bind and st_visibility

["ishitatsuyuki at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #2 from Tatsuyuki Ishi <ishitatsuyuki at gmail dot com> ---
Created attachment 53164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53164&action=edit
A source that fails to link when ltrans is grabbed separatedly and passed to
link

Here's a minimized test case from the linked mold issue for the purpose of
reproducing the issue.

For normal LTO usage, it compiles fine with `g++ main.cpp
/usr/lib/libboost_fiber.a /usr/lib/libboost_context.a -flto`. We now add
`-save-temps` to grab a copy of the ltrans output.

Then, we grab the command line used to link through `-v`, then pass the ltrans
object to ld directly. It will give you a duplicate symbol error. Exact command
line attached below.

$ ld --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -pie
/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/Scrt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/crtbeginS.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0
-L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../..
a.ltrans0.ltrans.o /usr/lib/libboost_fiber.a /usr/lib/libboost_context.a
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/crtn.o 
ld:
/usr/lib/libboost_fiber.a(condition_variable.o):(.tbss._ZGVZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator[_ZGVZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator]+0x0):
multiple definition of `guard variable for
boost::fibers::detail::spinlock_ttas::lock()::generator';
a.ltrans0.ltrans.o:(.tbss+0x8): first defined here
ld:
/usr/lib/libboost_fiber.a(condition_variable.o):(.tbss._ZZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator[_ZZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator]+0x0):
multiple definition of
`boost::fibers::detail::spinlock_ttas::lock()::generator';
a.ltrans0.ltrans.o:(.tbss+0x0): first defined here

To ensure successful resolution with GNU_UNIQUE TLS symbols, you need either
WEAK symbols or COMDAT groups. GCC ltrans contains neither. When used with the
LTO plugin, it inherits the weak st_bind from IR objects, and passes through
the fallback WEAK symbols based resolution for duplicate C++ definitions (we
usually use COMDAT). When you don't have the LTO plugin, boom, it's a GLOBAL
symbol vs UNIQUE symbol which is a conflict without question.