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

73 lines
2.1 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
// RUN: ld.lld -shared %t.o -o %t.so
// RUN: llvm-objdump -d %t.so | FileCheck %s
// 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.
[ELF] Set max page size to 64K for AArch64 Differential revision: https://reviews.llvm.org/D25079 llvm-svn: 283200
2016-10-04 16:58:55 +08:00
// CHECK: 10000: {{.*}} adrp x0, #65536
// CHECK-NEXT: 10004: {{.*}} ldr x1, [x0, #144]
// CHECK-NEXT: 10008: {{.*}} add x0, x0, #144
// CHECK-NEXT: 1000c: {{.*}} 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
// CHECK: 10010: {{.*}} adrp x0, #65536
// CHECK-NEXT: 10014: {{.*}} ldr x1, [x0, #160]
// CHECK-NEXT: 10018: {{.*}} add x0, x0, #160
// CHECK-NEXT: 1001c: {{.*}} blr x1
adrp x0, :tlsdesc:local2
ldr x1, [x0, :tlsdesc_lo12:local2]
add x0, x0, :tlsdesc_lo12:local2
.tlsdesccall a
blr x1
// CHECK: 10020: {{.*}} adrp x0, #65536
// CHECK-NEXT: 10024: {{.*}} ldr x1, [x0, #176]
// CHECK-NEXT: 10028: {{.*}} add x0, x0, #176
// CHECK-NEXT: 1002c: {{.*}} blr x1
.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: 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
// REL-NEXT: 0x200A0 R_AARCH64_TLSDESC - 0x0
// REL-NEXT: 0x200B0 R_AARCH64_TLSDESC - 0x8
[ELF] Set max page size to 64K for AArch64 Differential revision: https://reviews.llvm.org/D25079 llvm-svn: 283200
2016-10-04 16:58:55 +08:00
// REL-NEXT: 0x20090 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: ]