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

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

[ishitatsuyuki at gmail dot com]

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

            Bug ID: 105933
           Summary: LTO ltrans object files does not have proper st_bind
                    and st_visibility
           Product: gcc
           Version: 12.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ishitatsuyuki at gmail dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

It looks like the .ltrans.o object files emitted by GCC gold plugin does not
specify the `st_bind` and `st_visibility` attributes properly, and instead
relies on the linker to somehow carry them over from the information passed
from `add_symbols`.

This is causing issues in mold (https://github.com/rui314/mold/issues/524), for
cases of TLS symbols which uses GNU_UNIQUE instead of WEAK and cannot be
overridden. In mold we just throw away the IR object files and symbols once we
get the LTO output, doing the name resolution again --- and therefore the
assumption made for gold does not hold here. 

I'd argue this design is not great for debugging as well, as it creates an
object file that can be only linked while using the LTO plugin; if the
individual object files are directly passed to the linker through command-line,
then it results in a duplicate symbols error.

On a separate topic, it looks like we're missing COMDAT information as well ---
which AFAIK cannot be passed through any of the gold plugin API, unlike
`add_symbols`. Due to weird interactions between weak symbols in the main
object files and strong symbols in a static library, I think mold requires the
COMDAT to deduplicate the sections beforehand in this case, even if it's not
strictly necessary by the spec. So we would appreciate if you could include
that information in the LTO output too.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You are refering to the LTRANS objects created from the LTRANS compile phase.
These should be perfectly valid to link and have correct st_bind/visibility,
but not necessarily the same as originally since link optimization combines
multiple TUs and distributes them to multiple LTRANS units, requiring former
local symbols to refer to each other from different LTRANS units.

Do you have a testcase that shows linking not-through-the-plugin doesn't work?

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

[ishitatsuyuki at gmail dot com]

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.