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-tls-le.s

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

49 lines
1.2 KiB
ArmAsm
Raw Normal View History

[ELF] Move `# REQUIRES:` line to the top llvm-svn: 335625
2018-06-27 00:58:19 +08:00
# REQUIRES: aarch64
Run dos2unix. NFC. llvm-svn: 263238
2016-03-11 22:34:44 +08:00
# RUN: llvm-mc -filetype=obj -triple=aarch64-unknown-freebsd %s -o %tmain.o
# RUN: ld.lld %tmain.o -o %tout
# RUN: llvm-objdump -d %tout | FileCheck %s
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj -S -r %tout | FileCheck -check-prefix=RELOC %s
Run dos2unix. NFC. llvm-svn: 263238
2016-03-11 22:34:44 +08:00
[ARM][AArch64] Increase TLS alignment to reserve space for Android's TCB ARM and AArch64 use TLS variant 1, where the first two words after the thread pointer are reserved for the TCB, followed by the executable's TLS segment. Both the thread pointer and the TLS segment are aligned to at least the TLS segment's alignment. Android/Bionic historically has not supported ELF TLS, and it has allocated memory after the thread pointer for several Bionic TLS slots (currently 9 but soon only 8). At least one of these allocations (TLS_SLOT_STACK_GUARD == 5) is widespread throughout Android/AArch64 binaries and can't be changed. To reconcile this disagreement about TLS memory layout, set the minimum alignment for executable TLS segments to 8 words on ARM/AArch64, which reserves at least 8 words of memory after the TP (2 for the ABI-specified TCB and 6 for alignment padding). For simplicity, and because lld doesn't know when it's targeting Android, increase the alignment regardless of operating system. Differential Revision: https://reviews.llvm.org/D53906 llvm-svn: 350681
2019-01-09 08:09:59 +08:00
#Local-Dynamic to Local-Exec relax creates no
Run dos2unix. NFC. llvm-svn: 263238
2016-03-11 22:34:44 +08:00
#RELOC: Relocations [
#RELOC-NEXT: ]
.globl _start
_start:
mrs x0, TPIDR_EL0
add x0, x0, :tprel_hi12:v1
add x0, x0, :tprel_lo12_nc:v1
[AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12 Summary: An AArch64 LE relocation is a positive ("variant 1") offset. This relocation is used to write the upper 12 bits of a 24-bit offset into an add instruction: add x0, x0, :tprel_hi12:v1 The comment in the ARM docs for R_AARCH64_TLSLE_ADD_TPREL_HI12 is: "Set an ADD immediate field to bits [23:12] of X; check 0 <= X < 2^24." Reviewers: javed.absar, espindola, ruiu, peter.smith, zatrazz Reviewed By: ruiu Subscribers: emaste, arichardson, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D52525 llvm-svn: 343144
2018-09-27 04:50:38 +08:00
mrs x0, TPIDR_EL0
add x0, x0, :tprel_hi12:v2
add x0, x0, :tprel_lo12_nc:v2
Run dos2unix. NFC. llvm-svn: 263238
2016-03-11 22:34:44 +08:00
[ARM][AArch64] Revert Android Bionic PT_TLS overaligning hack This reverts D53906. D53906 increased p_align of PT_TLS on ARM/AArch64 to 32/64 to make the static TLS layout compatible with Android Bionic's ELF TLS. However, this may cause glibc ARM/AArch64 programs to crash (see PR41527). The faulty PT_TLS in the executable satisfies p_vaddr%p_align != 0. The remainder is normally 0 but may be non-zero with the hack in place. The problem is that we increase PT_TLS's p_align after OutputSections' addresses are fixed (assignAddress()). It is possible that p_vaddr%old_p_align = 0 while p_vaddr%new_p_align != 0. For a thread local variable defined in the executable, lld computed TLS offset (local exec) is different from glibc computed TLS offset from another module (initial exec/generic dynamic). Note: PR41527 said the bug affects initial exec but actually generic dynamic is affected as well. (glibc is correct in that it compute offsets that satisfy `offset%p_align == p_vaddr%p_align`, which is a basic ELF requirement. This hack appears to work on FreeBSD rtld, musl<=1.1.22, and Bionic, but that is just because they (and lld) incorrectly compute offsets that satisfy `offset%p_align = 0` instead.) Android developers are fine to revert this patch, carry this patch in their tree before figuring out a long-term solution (e.g. a dummy .tdata with sh_addralign=64 sh_size={0,1} in crtbegin*.o files. The overhead is now insignificant after D62059). Reviewed By: rprichard, srhines Differential Revision: https://reviews.llvm.org/D62055 llvm-svn: 361090
2019-05-18 11:16:00 +08:00
# TCB size = 0x16 and foo is first element from TLS register.
Run dos2unix. NFC. llvm-svn: 263238
2016-03-11 22:34:44 +08:00
#CHECK: Disassembly of section .text:
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
#CHECK: <_start>:
[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: 210158: 40 d0 3b d5 mrs x0, TPIDR_EL0
#CHECK: 21015c: 00 00 40 91 add x0, x0, #0, lsl #12
#CHECK: 210160: 00 40 00 91 add x0, x0, #16
#CHECK: 210164: 40 d0 3b d5 mrs x0, TPIDR_EL0
#CHECK: 210168: 00 fc 7f 91 add x0, x0, #4095, lsl #12
#CHECK: 21016c: 00 e0 3f 91 add x0, x0, #4088
Run dos2unix. NFC. llvm-svn: 263238
2016-03-11 22:34:44 +08:00
.section .tbss,"awT",@nobits
[AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12 Summary: An AArch64 LE relocation is a positive ("variant 1") offset. This relocation is used to write the upper 12 bits of a 24-bit offset into an add instruction: add x0, x0, :tprel_hi12:v1 The comment in the ARM docs for R_AARCH64_TLSLE_ADD_TPREL_HI12 is: "Set an ADD immediate field to bits [23:12] of X; check 0 <= X < 2^24." Reviewers: javed.absar, espindola, ruiu, peter.smith, zatrazz Reviewed By: ruiu Subscribers: emaste, arichardson, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D52525 llvm-svn: 343144
2018-09-27 04:50:38 +08:00
.type v1,@object
Run dos2unix. NFC. llvm-svn: 263238
2016-03-11 22:34:44 +08:00
.globl v1
.p2align 2
v1:
.word 0
.size v1, 4
[ARM][AArch64] Revert Android Bionic PT_TLS overaligning hack This reverts D53906. D53906 increased p_align of PT_TLS on ARM/AArch64 to 32/64 to make the static TLS layout compatible with Android Bionic's ELF TLS. However, this may cause glibc ARM/AArch64 programs to crash (see PR41527). The faulty PT_TLS in the executable satisfies p_vaddr%p_align != 0. The remainder is normally 0 but may be non-zero with the hack in place. The problem is that we increase PT_TLS's p_align after OutputSections' addresses are fixed (assignAddress()). It is possible that p_vaddr%old_p_align = 0 while p_vaddr%new_p_align != 0. For a thread local variable defined in the executable, lld computed TLS offset (local exec) is different from glibc computed TLS offset from another module (initial exec/generic dynamic). Note: PR41527 said the bug affects initial exec but actually generic dynamic is affected as well. (glibc is correct in that it compute offsets that satisfy `offset%p_align == p_vaddr%p_align`, which is a basic ELF requirement. This hack appears to work on FreeBSD rtld, musl<=1.1.22, and Bionic, but that is just because they (and lld) incorrectly compute offsets that satisfy `offset%p_align = 0` instead.) Android developers are fine to revert this patch, carry this patch in their tree before figuring out a long-term solution (e.g. a dummy .tdata with sh_addralign=64 sh_size={0,1} in crtbegin*.o files. The overhead is now insignificant after D62059). Reviewed By: rprichard, srhines Differential Revision: https://reviews.llvm.org/D62055 llvm-svn: 361090
2019-05-18 11:16:00 +08:00
# The current offset from the thread pointer is 20. Raise it to just below the
[AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12 Summary: An AArch64 LE relocation is a positive ("variant 1") offset. This relocation is used to write the upper 12 bits of a 24-bit offset into an add instruction: add x0, x0, :tprel_hi12:v1 The comment in the ARM docs for R_AARCH64_TLSLE_ADD_TPREL_HI12 is: "Set an ADD immediate field to bits [23:12] of X; check 0 <= X < 2^24." Reviewers: javed.absar, espindola, ruiu, peter.smith, zatrazz Reviewed By: ruiu Subscribers: emaste, arichardson, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D52525 llvm-svn: 343144
2018-09-27 04:50:38 +08:00
# 24-bit limit.
[ARM][AArch64] Revert Android Bionic PT_TLS overaligning hack This reverts D53906. D53906 increased p_align of PT_TLS on ARM/AArch64 to 32/64 to make the static TLS layout compatible with Android Bionic's ELF TLS. However, this may cause glibc ARM/AArch64 programs to crash (see PR41527). The faulty PT_TLS in the executable satisfies p_vaddr%p_align != 0. The remainder is normally 0 but may be non-zero with the hack in place. The problem is that we increase PT_TLS's p_align after OutputSections' addresses are fixed (assignAddress()). It is possible that p_vaddr%old_p_align = 0 while p_vaddr%new_p_align != 0. For a thread local variable defined in the executable, lld computed TLS offset (local exec) is different from glibc computed TLS offset from another module (initial exec/generic dynamic). Note: PR41527 said the bug affects initial exec but actually generic dynamic is affected as well. (glibc is correct in that it compute offsets that satisfy `offset%p_align == p_vaddr%p_align`, which is a basic ELF requirement. This hack appears to work on FreeBSD rtld, musl<=1.1.22, and Bionic, but that is just because they (and lld) incorrectly compute offsets that satisfy `offset%p_align = 0` instead.) Android developers are fine to revert this patch, carry this patch in their tree before figuring out a long-term solution (e.g. a dummy .tdata with sh_addralign=64 sh_size={0,1} in crtbegin*.o files. The overhead is now insignificant after D62059). Reviewed By: rprichard, srhines Differential Revision: https://reviews.llvm.org/D62055 llvm-svn: 361090
2019-05-18 11:16:00 +08:00
.space (0xfffff8 - 20)
[AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12 Summary: An AArch64 LE relocation is a positive ("variant 1") offset. This relocation is used to write the upper 12 bits of a 24-bit offset into an add instruction: add x0, x0, :tprel_hi12:v1 The comment in the ARM docs for R_AARCH64_TLSLE_ADD_TPREL_HI12 is: "Set an ADD immediate field to bits [23:12] of X; check 0 <= X < 2^24." Reviewers: javed.absar, espindola, ruiu, peter.smith, zatrazz Reviewed By: ruiu Subscribers: emaste, arichardson, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D52525 llvm-svn: 343144
2018-09-27 04:50:38 +08:00
.type v2,@object
.globl v2
.p2align 2
v2:
.word 0
.size v2, 4