https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118473
Bug ID: 118473
Summary: ELF visibility of compiler declared symbols
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
At the example of __stack_chk_guard, accesses to which result from
-fstack-protector -mstack-protector-guard=global, there is a problem for
special purpose environments like the Xen hypervisor. For access efficiency
reasons all symbols we declare there are forced to be hidden. The (x86-64)
binary is small enough for all code and data to be accessible via %rip-relative
means.
With everything forced to be hidden we further assert, in the linker script,
that .got is empty.
Problems arise when it comes to compiler declared symbols. Re-declaring them
with visibility switched to be hidden by default doesn't appear to alter
earlier declarations that the compiler synthesized internally. While seemingly
not a big problem for functions (e.g. memset() and memcpy()), __stack_chk_guard
- being a data item - is then accessed using @gotpcrel operand modifiers.
Leaving aside that GNU ld then also can't deal with this correctly unless
passed --no-relax (at which point .got will end up non-empty), the main request
here is: Can we please have a means to override visibility of compiler-declared
symbols? Should such internal declarations perhaps respect -fvisibility=? (This
may not suffice in our case, as we control visibility via #pragma instead. It
may be possible for us to switch to using the command line option.)
