[ELF] Set Out::TlsPhdr earlier for encoding packed reloc tables
Summary:
For --pack-dyn-relocs=android, finalizeSections calls
LinkerScript::assignAddresses and
AndroidPackedRelocationSection::updateAllocSize in a loop,
where assignAddresses lays out the ELF image, then updateAllocSize
determines the size of the Android packed relocation table by encoding it.
Encoding the table requires knowing the values of relocation addends.
To get the addend of a TLS relocation, updateAllocSize can call getSymVA
on a TLS symbol before setPhdrs has initialized Out::TlsPhdr, producing an
error:
<file> has an STT_TLS symbol but doesn't have an SHF_TLS section
Fix the problem by initializing Out::TlsPhdr immediately after the program
headers are created. The segment's p_vaddr field isn't initialized until
setPhdrs, so use FirstSec->Addr, which is what setPhdrs would use.
FirstSec will typically refer to the .tdata or .tbss output section, whose
(tentative) address was computed by assignAddresses.
Android currently avoids this problem because it uses emutls and doesn't
support ELF TLS. This problem doesn't apply to --pack-dyn-relocs=relr
because SHR_RELR only handles relative relocations without explicit addends
or info.
Fixes https://bugs.llvm.org/show_bug.cgi?id=37841.
Reviewers: ruiu, pcc, chh, javed.absar, espindola
Subscribers: emaste, arichardson, llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D51671
llvm-svn: 342432
2018-09-18 08:24:48 +08:00
|
|
|
// REQUIRES: aarch64
|
|
|
|
|
|
|
|
|
|
// RUN: llvm-mc -filetype=obj -triple=aarch64-unknown-linux %s -o %t.o
|
|
|
|
|
// RUN: ld.lld -shared --pack-dyn-relocs=android %t.o -o %t.so
|
2019-05-01 13:49:01 +08:00
|
|
|
// RUN: llvm-readobj -r %t.so | FileCheck %s
|
[ELF] Set Out::TlsPhdr earlier for encoding packed reloc tables
Summary:
For --pack-dyn-relocs=android, finalizeSections calls
LinkerScript::assignAddresses and
AndroidPackedRelocationSection::updateAllocSize in a loop,
where assignAddresses lays out the ELF image, then updateAllocSize
determines the size of the Android packed relocation table by encoding it.
Encoding the table requires knowing the values of relocation addends.
To get the addend of a TLS relocation, updateAllocSize can call getSymVA
on a TLS symbol before setPhdrs has initialized Out::TlsPhdr, producing an
error:
<file> has an STT_TLS symbol but doesn't have an SHF_TLS section
Fix the problem by initializing Out::TlsPhdr immediately after the program
headers are created. The segment's p_vaddr field isn't initialized until
setPhdrs, so use FirstSec->Addr, which is what setPhdrs would use.
FirstSec will typically refer to the .tdata or .tbss output section, whose
(tentative) address was computed by assignAddresses.
Android currently avoids this problem because it uses emutls and doesn't
support ELF TLS. This problem doesn't apply to --pack-dyn-relocs=relr
because SHR_RELR only handles relative relocations without explicit addends
or info.
Fixes https://bugs.llvm.org/show_bug.cgi?id=37841.
Reviewers: ruiu, pcc, chh, javed.absar, espindola
Subscribers: emaste, arichardson, llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D51671
llvm-svn: 342432
2018-09-18 08:24:48 +08:00
|
|
|
|
|
|
|
|
// Bug 37841: Symbol::getVA must work on TLS symbols during the layout loop in
|
|
|
|
|
// finalizeSections.
|
|
|
|
|
|
|
|
|
|
.global foo
|
|
|
|
|
foo:
|
|
|
|
|
adrp x0, :tlsdesc:tlsvar1
|
|
|
|
|
ldr x1, [x0, :tlsdesc_lo12:tlsvar1]
|
|
|
|
|
add x0, x0, :tlsdesc_lo12:tlsvar1
|
|
|
|
|
.tlsdesccall tlsvar1
|
|
|
|
|
|
|
|
|
|
// Also test an atypical IE access from a shared object to a local TLS symbol.
|
|
|
|
|
|
|
|
|
|
.global bar
|
|
|
|
|
bar:
|
|
|
|
|
adrp x0, :gottprel:tlsvar2
|
|
|
|
|
ldr x0, [x0, #:gottprel_lo12:tlsvar2]
|
|
|
|
|
|
|
|
|
|
.section .tdata,"awT",@progbits
|
|
|
|
|
.space 0x1234
|
|
|
|
|
tlsvar1:
|
|
|
|
|
.word 42
|
|
|
|
|
tlsvar2:
|
|
|
|
|
.word 17
|
|
|
|
|
|
|
|
|
|
// CHECK: Section ({{.+}}) .rela.dyn {
|
|
|
|
|
// CHECK-NEXT: R_AARCH64_TLSDESC - 0x1234
|
|
|
|
|
// CHECK-NEXT: R_AARCH64_TLS_TPREL64 - 0x1238
|
|
|
|
|
// CHECK-NEXT: }
|