https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
Bug ID: 98112
Summary: Add -fdirect-access-external-data & drop
HAVE_LD_PIE_COPYRELOC
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
After "x86-64: Optimize access to globals in PIE with copy reloc", GCC x86-64
asks the assembler to produce an R_X86_64_PC32 for an external data access.
* It introduced a configure-time variable HAVE_LD_PIE_COPYRELOC which has a
misleading name: PC32 does not necessarily cause a copy relocation.
If the external data
* It affects users who want to configure GCC not to emit R_X86_64_PC32 for an
external data access so that copy relocations can be avoided if the data turns
out to be defined in a different shared object/executable
* While it made sense (in turns of performance) before H.J. Lu added GOTPCRELX
to x86-64, it hardly matters if any nowadays.
* This optimization can actually benefit non-x86-64. An option is more
suitable.
In Clang, the GCC style HAVE_LD_PIE_COPYRELOC is implemented as
-mpie-copy-relocations, which has a misleading name.
I agree that this should be implemented as an option, instead of a
configure-time variable.
I suggest that we add a new architecture-independent option
-f[no-]direct-access-external-data (I am happy to add a similar one in Clang
once consensus is made) and delete HAVE_LD_PIE_COPYRELOC. The option means
whether a direct access (PC-relative relocation) can be generated for an
external data access.
The value can default to true for -fno-pic code (it seems that most
architectures behave this way).
For non-x86-64, the value defaults to false for -fpie/-fpic code (I believe
most architectures use a GOT).
In the future, for x86-64, please consider defaulting to
-fno-direct-access-external-data for -fpie/-fpic so that issues related to
STV_PROTECTED data can be properly fixed (see my analysis last year
https://gcc.gnu.org/legacy-ml/gcc/2019-05/msg00215.html )
