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.
