summaryrefslogtreecommitdiffstats
path: root/lld/test/ELF/copy-rel-tls.s
Commit message (Collapse)AuthorAgeFilesLines
* [ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_X86_64Fangrui Song2019-09-161-2/+2
| | | | | | | | Port the D64906 technique to EM_X86_64. Differential Revision: https://reviews.llvm.org/D67482 llvm-svn: 371958
* [ELF] Don't copy STT_TLS in copy relocationFangrui Song2018-08-061-0/+15
During copy relocation of a variable defined in a DSO, if a TLS variable in that DSO happens to have the same st_value, it would also be copied. This was unnecessary because the addresses of TLS variables are relative to TLS segment. They don't interfere with non-TLS variables. This copying behavior can be harmful in the following scenario: For function-scope thread-local variables with non-trivial constructors, they have guard variables. In the case of x86_64 general-dynamic model: template <int N> void foo() { thread_local std::string a; } GOT[n] R_X86_64_DTPMOD64 guard variable for a GOT[n+1] R_X86_64_DTPOFF64 guard variable for a GOT[n+2] R_X86_64_DTPMOD64 a GOT[n+3] R_X86_64_DTPOFF64 a a and its guard variable are both represented as TLS variables, which should be within the same module. If one is copy relocated to the main module while the other is not, their module ID will mismatch and can cause access without prior construction. Reviewers: ruiu, espindola Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D50289 llvm-svn: 339042
OpenPOWER on IntegriCloud