[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.