maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/aarch64-tlsdesc.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

73 lines
2.0 KiB
ArmAsm
Raw Normal View History

Start adding tlsdesc support for aarch64. This is mostly extracted from http://reviews.llvm.org/D18960. The general idea for tlsdesc is that the two GD got entries are used for a function pointer and its argument. The dynamic linker sets both. In the non-dlopen case the dynamic linker sets the function to the identity and the argument to the offset in the tls block. All that the static linker has to do in the non-dlopen case is relocate the code to point to the got entries and create a dynamic relocation. The dlopen case is more complicated, but can be implemented in another patch. llvm-svn: 271569
2016-06-03 03:49:53 +08:00
// REQUIRES: aarch64
// RUN: llvm-mc -filetype=obj -triple=aarch64-pc-linux %s -o %t.o
[ELF] - Do --hash-style=both by default. Its PR34712, GNU linkers recently changed default values to "both" of "sysv". Patch do the same for all targets except MIPS, where .gnu.hash section is not yet supported. Code suggested by Rui Ueyama. Differential revision: https://reviews.llvm.org/D38407 llvm-svn: 315051
2017-10-06 17:37:44 +08:00
// RUN: ld.lld --hash-style=sysv -shared %t.o -o %t.so
[ELF][AArch64] Improve some aarch64-*.s tests * Delete aarch64-tls-static.s: it is covered by aarch64-tlsdesc.c * Add --no-show-raw-insn to llvm-objdump -d tests * When linking an executable with %t.so, the path %t.so will be recorded in the DT_NEEDED entry if %t.so doesn't have DT_SONAME. The DT_NEEDED has varying lengths on different systems. Add -soname to make tests more robust. This issue will become outstanding if we allow overlapping PT_LOAD (D64930). llvm-svn: 366532
2019-07-19 14:33:36 +08:00
// RUN: llvm-objdump -d --no-show-raw-insn %t.so | FileCheck %s
Start adding tlsdesc support for aarch64. This is mostly extracted from http://reviews.llvm.org/D18960. The general idea for tlsdesc is that the two GD got entries are used for a function pointer and its argument. The dynamic linker sets both. In the non-dlopen case the dynamic linker sets the function to the identity and the argument to the offset in the tls block. All that the static linker has to do in the non-dlopen case is relocate the code to point to the got entries and create a dynamic relocation. The dlopen case is more complicated, but can be implemented in another patch. llvm-svn: 271569
2016-06-03 03:49:53 +08:00
// RUN: llvm-readobj -r %t.so | FileCheck --check-prefix=REL %s
ELF/AArch64: Fix dynamic relocation against local symbol in shared objects AArch64 TLSDESC for local symbol in shared objects are implemented in a arch specific manner where the TLSDESC dynamic relocation addend is the symbol VM inside the TLS block. For instance, with a shared library created from the code: -- static __thread int32_t x1; static __thread int64_t x2; int32_t foo1 (int32_t x) { x1 += x; return x; } int64_t foo2 (int64_t x) { x2 += x; return x; } -- The dynamic relocation should be create as: Relocations [ Section (N) .rela.dyn { <Address1> R_AARCH64_TLSDESC - 0x0 <Address2> R_AARCH64_TLSDESC - 0x8 } ] Where 0x0 addend in first dynamic relocation is the address of 'x1' in TLS block and '0x8' is the address of 'x2'. Checked against test-suite on aarch64-linux-gnu. llvm-svn: 290099
2016-12-19 19:58:01 +08:00
.text
Start adding tlsdesc support for aarch64. This is mostly extracted from http://reviews.llvm.org/D18960. The general idea for tlsdesc is that the two GD got entries are used for a function pointer and its argument. The dynamic linker sets both. In the non-dlopen case the dynamic linker sets the function to the identity and the argument to the offset in the tls block. All that the static linker has to do in the non-dlopen case is relocate the code to point to the got entries and create a dynamic relocation. The dlopen case is more complicated, but can be implemented in another patch. llvm-svn: 271569
2016-06-03 03:49:53 +08:00
adrp x0, :tlsdesc:a
ldr x1, [x0, :tlsdesc_lo12:a]
add x0, x0, :tlsdesc_lo12:a
.tlsdesccall a
blr x1
ELF/AArch64: Fix dynamic relocation against local symbol in shared objects AArch64 TLSDESC for local symbol in shared objects are implemented in a arch specific manner where the TLSDESC dynamic relocation addend is the symbol VM inside the TLS block. For instance, with a shared library created from the code: -- static __thread int32_t x1; static __thread int64_t x2; int32_t foo1 (int32_t x) { x1 += x; return x; } int64_t foo2 (int64_t x) { x2 += x; return x; } -- The dynamic relocation should be create as: Relocations [ Section (N) .rela.dyn { <Address1> R_AARCH64_TLSDESC - 0x0 <Address2> R_AARCH64_TLSDESC - 0x8 } ] Where 0x0 addend in first dynamic relocation is the address of 'x1' in TLS block and '0x8' is the address of 'x2'. Checked against test-suite on aarch64-linux-gnu. llvm-svn: 290099
2016-12-19 19:58:01 +08:00
// Create relocation against local TLS symbols where linker should
// create target specific dynamic TLSDESC relocation where addend is
// the symbol VMA in tls block.
[AArch64InstPrinter] Change printADRPLabel to print the target address in hexadecimal form Similar to D77853. Change ADRP to print the target address in hex, instead of the raw immediate. The behavior is similar to GNU objdump but we also include `0x`. Note: GNU objdump is not consistent whether or not to emit `0x` for different architectures. We try emitting 0x consistently for all targets. ``` GNU objdump: adrp x16, 10000000 Old llvm-objdump: adrp x16, #0 New llvm-objdump: adrp x16, 0x10000000 ``` `adrp Xd, 0x...` assembles to a relocation referencing `*ABS*+0x10000` which is not intended. We need to use a linker or use yaml2obj. The main test is `test/tools/llvm-objdump/ELF/AArch64/pcrel-address.yaml` Differential Revision: https://reviews.llvm.org/D93241
2020-12-17 01:20:55 +08:00
// CHECK: 10298: adrp x0, 0x20000
[ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges Ported the D64906 technique to AArch64. It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of an aarch64 binary decreases by at most 192kb. If `sh_addralign(.tdata) < sh_addralign(.tbss)`, we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0`. ld.so that are known to have problems if p_vaddr%p_align!=0: * musl<=1.1.22 * FreeBSD 13.0-CURRENT (and before) rtld-elf arm64 New test aarch64-tls-vaddr-align.s checks that our workaround makes p_vaddr%p_align = 0. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64930 llvm-svn: 369344
2019-08-20 16:34:56 +08:00
// CHECK-NEXT: 1029c: ldr x1, [x0, #856]
// CHECK-NEXT: 102a0: add x0, x0, #856
// CHECK-NEXT: 102a4: blr x1
Start adding tlsdesc support for aarch64. This is mostly extracted from http://reviews.llvm.org/D18960. The general idea for tlsdesc is that the two GD got entries are used for a function pointer and its argument. The dynamic linker sets both. In the non-dlopen case the dynamic linker sets the function to the identity and the argument to the offset in the tls block. All that the static linker has to do in the non-dlopen case is relocate the code to point to the got entries and create a dynamic relocation. The dlopen case is more complicated, but can be implemented in another patch. llvm-svn: 271569
2016-06-03 03:49:53 +08:00
ELF/AArch64: Fix dynamic relocation against local symbol in shared objects AArch64 TLSDESC for local symbol in shared objects are implemented in a arch specific manner where the TLSDESC dynamic relocation addend is the symbol VM inside the TLS block. For instance, with a shared library created from the code: -- static __thread int32_t x1; static __thread int64_t x2; int32_t foo1 (int32_t x) { x1 += x; return x; } int64_t foo2 (int64_t x) { x2 += x; return x; } -- The dynamic relocation should be create as: Relocations [ Section (N) .rela.dyn { <Address1> R_AARCH64_TLSDESC - 0x0 <Address2> R_AARCH64_TLSDESC - 0x8 } ] Where 0x0 addend in first dynamic relocation is the address of 'x1' in TLS block and '0x8' is the address of 'x2'. Checked against test-suite on aarch64-linux-gnu. llvm-svn: 290099
2016-12-19 19:58:01 +08:00
adrp x0, :tlsdesc:local1
ldr x1, [x0, :tlsdesc_lo12:local1]
add x0, x0, :tlsdesc_lo12:local1
.tlsdesccall a
blr x1
[AArch64InstPrinter] Change printADRPLabel to print the target address in hexadecimal form Similar to D77853. Change ADRP to print the target address in hex, instead of the raw immediate. The behavior is similar to GNU objdump but we also include `0x`. Note: GNU objdump is not consistent whether or not to emit `0x` for different architectures. We try emitting 0x consistently for all targets. ``` GNU objdump: adrp x16, 10000000 Old llvm-objdump: adrp x16, #0 New llvm-objdump: adrp x16, 0x10000000 ``` `adrp Xd, 0x...` assembles to a relocation referencing `*ABS*+0x10000` which is not intended. We need to use a linker or use yaml2obj. The main test is `test/tools/llvm-objdump/ELF/AArch64/pcrel-address.yaml` Differential Revision: https://reviews.llvm.org/D93241
2020-12-17 01:20:55 +08:00
// CHECK: 102a8: adrp x0, 0x20000
[ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges Ported the D64906 technique to AArch64. It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of an aarch64 binary decreases by at most 192kb. If `sh_addralign(.tdata) < sh_addralign(.tbss)`, we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0`. ld.so that are known to have problems if p_vaddr%p_align!=0: * musl<=1.1.22 * FreeBSD 13.0-CURRENT (and before) rtld-elf arm64 New test aarch64-tls-vaddr-align.s checks that our workaround makes p_vaddr%p_align = 0. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64930 llvm-svn: 369344
2019-08-20 16:34:56 +08:00
// CHECK-NEXT: 102ac: ldr x1, [x0, #872]
// CHECK-NEXT: 102b0: add x0, x0, #872
// CHECK-NEXT: 102b4: blr x1
ELF/AArch64: Fix dynamic relocation against local symbol in shared objects AArch64 TLSDESC for local symbol in shared objects are implemented in a arch specific manner where the TLSDESC dynamic relocation addend is the symbol VM inside the TLS block. For instance, with a shared library created from the code: -- static __thread int32_t x1; static __thread int64_t x2; int32_t foo1 (int32_t x) { x1 += x; return x; } int64_t foo2 (int64_t x) { x2 += x; return x; } -- The dynamic relocation should be create as: Relocations [ Section (N) .rela.dyn { <Address1> R_AARCH64_TLSDESC - 0x0 <Address2> R_AARCH64_TLSDESC - 0x8 } ] Where 0x0 addend in first dynamic relocation is the address of 'x1' in TLS block and '0x8' is the address of 'x2'. Checked against test-suite on aarch64-linux-gnu. llvm-svn: 290099
2016-12-19 19:58:01 +08:00
adrp x0, :tlsdesc:local2
ldr x1, [x0, :tlsdesc_lo12:local2]
add x0, x0, :tlsdesc_lo12:local2
.tlsdesccall a
blr x1
[AArch64InstPrinter] Change printADRPLabel to print the target address in hexadecimal form Similar to D77853. Change ADRP to print the target address in hex, instead of the raw immediate. The behavior is similar to GNU objdump but we also include `0x`. Note: GNU objdump is not consistent whether or not to emit `0x` for different architectures. We try emitting 0x consistently for all targets. ``` GNU objdump: adrp x16, 10000000 Old llvm-objdump: adrp x16, #0 New llvm-objdump: adrp x16, 0x10000000 ``` `adrp Xd, 0x...` assembles to a relocation referencing `*ABS*+0x10000` which is not intended. We need to use a linker or use yaml2obj. The main test is `test/tools/llvm-objdump/ELF/AArch64/pcrel-address.yaml` Differential Revision: https://reviews.llvm.org/D93241
2020-12-17 01:20:55 +08:00
// CHECK: 102b8: adrp x0, 0x20000
[ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges Ported the D64906 technique to AArch64. It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of an aarch64 binary decreases by at most 192kb. If `sh_addralign(.tdata) < sh_addralign(.tbss)`, we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0`. ld.so that are known to have problems if p_vaddr%p_align!=0: * musl<=1.1.22 * FreeBSD 13.0-CURRENT (and before) rtld-elf arm64 New test aarch64-tls-vaddr-align.s checks that our workaround makes p_vaddr%p_align = 0. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64930 llvm-svn: 369344
2019-08-20 16:34:56 +08:00
// CHECK-NEXT: 102bc: ldr x1, [x0, #888]
// CHECK-NEXT: 102c0: add x0, x0, #888
// CHECK-NEXT: 102c4: blr x1
ELF/AArch64: Fix dynamic relocation against local symbol in shared objects AArch64 TLSDESC for local symbol in shared objects are implemented in a arch specific manner where the TLSDESC dynamic relocation addend is the symbol VM inside the TLS block. For instance, with a shared library created from the code: -- static __thread int32_t x1; static __thread int64_t x2; int32_t foo1 (int32_t x) { x1 += x; return x; } int64_t foo2 (int64_t x) { x2 += x; return x; } -- The dynamic relocation should be create as: Relocations [ Section (N) .rela.dyn { <Address1> R_AARCH64_TLSDESC - 0x0 <Address2> R_AARCH64_TLSDESC - 0x8 } ] Where 0x0 addend in first dynamic relocation is the address of 'x1' in TLS block and '0x8' is the address of 'x2'. Checked against test-suite on aarch64-linux-gnu. llvm-svn: 290099
2016-12-19 19:58:01 +08:00
.section .tbss,"awT",@nobits
.type local1,@object
.p2align 2
local1:
.word 0
.size local1, 4
.type local2,@object
.p2align 3
local2:
.xword 0
.size local2, 8
// 0x1000 + 4096 + 160 = 0x20A0
// 0x1000 + 4096 + 176 = 0x20B0
Start adding tlsdesc support for aarch64. This is mostly extracted from http://reviews.llvm.org/D18960. The general idea for tlsdesc is that the two GD got entries are used for a function pointer and its argument. The dynamic linker sets both. In the non-dlopen case the dynamic linker sets the function to the identity and the argument to the offset in the tls block. All that the static linker has to do in the non-dlopen case is relocate the code to point to the got entries and create a dynamic relocation. The dlopen case is more complicated, but can be implemented in another patch. llvm-svn: 271569
2016-06-03 03:49:53 +08:00
// 0x1000 + 4096 + 144 = 0x2090
ELF/AArch64: Fix dynamic relocation against local symbol in shared objects AArch64 TLSDESC for local symbol in shared objects are implemented in a arch specific manner where the TLSDESC dynamic relocation addend is the symbol VM inside the TLS block. For instance, with a shared library created from the code: -- static __thread int32_t x1; static __thread int64_t x2; int32_t foo1 (int32_t x) { x1 += x; return x; } int64_t foo2 (int64_t x) { x2 += x; return x; } -- The dynamic relocation should be create as: Relocations [ Section (N) .rela.dyn { <Address1> R_AARCH64_TLSDESC - 0x0 <Address2> R_AARCH64_TLSDESC - 0x8 } ] Where 0x0 addend in first dynamic relocation is the address of 'x1' in TLS block and '0x8' is the address of 'x2'. Checked against test-suite on aarch64-linux-gnu. llvm-svn: 290099
2016-12-19 19:58:01 +08:00
// R_AARCH64_TLSDESC - 0x0 -> start of tls block
// R_AARCH64_TLSDESC - 0x8 -> align (sizeof (local1), 8)
Start adding tlsdesc support for aarch64. This is mostly extracted from http://reviews.llvm.org/D18960. The general idea for tlsdesc is that the two GD got entries are used for a function pointer and its argument. The dynamic linker sets both. In the non-dlopen case the dynamic linker sets the function to the identity and the argument to the offset in the tls block. All that the static linker has to do in the non-dlopen case is relocate the code to point to the got entries and create a dynamic relocation. The dlopen case is more complicated, but can be implemented in another patch. llvm-svn: 271569
2016-06-03 03:49:53 +08:00
// REL: Relocations [
// REL-NEXT: Section (4) .rela.dyn {
[ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges Ported the D64906 technique to AArch64. It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of an aarch64 binary decreases by at most 192kb. If `sh_addralign(.tdata) < sh_addralign(.tbss)`, we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0`. ld.so that are known to have problems if p_vaddr%p_align!=0: * musl<=1.1.22 * FreeBSD 13.0-CURRENT (and before) rtld-elf arm64 New test aarch64-tls-vaddr-align.s checks that our workaround makes p_vaddr%p_align = 0. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64930 llvm-svn: 369344
2019-08-20 16:34:56 +08:00
// REL-NEXT: 0x20368 R_AARCH64_TLSDESC - 0x0
// REL-NEXT: 0x20378 R_AARCH64_TLSDESC - 0x8
// REL-NEXT: 0x20358 R_AARCH64_TLSDESC a 0x0
Start adding tlsdesc support for aarch64. This is mostly extracted from http://reviews.llvm.org/D18960. The general idea for tlsdesc is that the two GD got entries are used for a function pointer and its argument. The dynamic linker sets both. In the non-dlopen case the dynamic linker sets the function to the identity and the argument to the offset in the tls block. All that the static linker has to do in the non-dlopen case is relocate the code to point to the got entries and create a dynamic relocation. The dlopen case is more complicated, but can be implemented in another patch. llvm-svn: 271569
2016-06-03 03:49:53 +08:00
// REL-NEXT: }
// REL-NEXT: ]