aboutsummaryrefslogtreecommitdiff
path: root/gmon
diff options
context:
space:
mode:
authorFangrui Song <maskray@google.com>2022-05-23 13:37:05 -0700
committerFangrui Song <maskray@google.com>2022-05-23 13:37:05 -0700
commite555954e026df1b85b8ef6c101d05f97b1520d7e (patch)
tree798159309b7d8a8dbed27f7e40fb999d6fa6b0cd /gmon
parenta8b11bd1f8dc68795b377138b5d94638ef75a50d (diff)
downloadglibc-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 'gmon')
0 files changed, 0 insertions, 0 deletions