diff options
author | Fangrui Song <maskray@google.com> | 2022-05-23 13:37:05 -0700 |
---|---|---|
committer | Fangrui Song <maskray@google.com> | 2022-05-23 13:37:05 -0700 |
commit | e555954e026df1b85b8ef6c101d05f97b1520d7e (patch) | |
tree | 798159309b7d8a8dbed27f7e40fb999d6fa6b0cd /LICENSES | |
parent | a8b11bd1f8dc68795b377138b5d94638ef75a50d (diff) | |
download | glibc-e555954e026df1b85b8ef6c101d05f97b1520d7e.zip glibc-e555954e026df1b85b8ef6c101d05f97b1520d7e.tar.gz glibc-e555954e026df1b85b8ef6c101d05f97b1520d7e.tar.bz2 |
Revert "[AArch64][BZ #17711] Fix extern protected data handling"
This reverts commit 0910702c4d2cf9e8302b35c9519548726e1ac489.
Say both a.so and b.so define protected data symbol `var` and the executable
copy relocates var. ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has strange
semantics: a.so accesses the copy in the executable while b.so accesses its
own. This behavior requires that (a) the compiler emits GOT-generating
relocations (b) the linker produces GLOB_DAT instead of RELATIVE.
Without the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA code, b.so's GLOB_DAT
will bind to the executable (normal behavior).
For aarch64 it makes sense to restore the original behavior and don't
pay the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA cost. The behavior is very
unlikely used by anyone.
* Clang code generator treats STV_PROTECTED the same way as STV_HIDDEN:
no GOT-generating relocation in the first place.
* gold and lld reject copy relocation on a STV_PROTECTED symbol.
* Nowadays -fpie/-fpic modes are popular. GCC/Clang's codegen uses
GOT-generating relocation when accessing an default visibility
external symbol which avoids copy relocation.
Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
Diffstat (limited to 'LICENSES')
0 files changed, 0 insertions, 0 deletions