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-gdle.s

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

26 lines
861 B
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-linux %p/Inputs/aarch64-tls-ie.s -o %ttlsie.o
# RUN: llvm-mc -filetype=obj -triple=aarch64-unknown-linux %s -o %tmain.o
# RUN: ld.lld %tmain.o %ttlsie.o -o %tout
[ELF][test] Reorganize some AArch64 tests Delete aarch64-got.s because it is covered by aarch64-tls-iele.s Merge got-aarch64.s into aarch64-fpic-got.s by adding disassembly to the latter Create aarch64-gnu-ifunc-nonpreemptable to unify aarch64-gnu-ifunc3.s (position-dependent executable) and aarch64-gnu-ifunc-address-pie.s (PIE) Rename aarch64-got-reloc.s to aarch64-got-weak-undef.s Add --no-show-raw-insn to llvm-objdump -d RUN lines Add -pie test to arch64-tls-iele.s Delete aarch64-tls-pie.s: it is covered by arch64-tls-iele.s and aarch64-tls-le.s Rename aarch64-copy2.s to aarch64-nopic-plt.s: "copy2" gives false impression that the test is related to copy relocation llvm-svn: 362294
2019-06-01 19:01:26 +08:00
# RUN: llvm-objdump -d --no-show-raw-insn %tout | FileCheck %s
# RUN: llvm-readobj -r %tout | FileCheck -check-prefix=RELOC %s
Run dos2unix. NFC. llvm-svn: 263238
2016-03-11 22:34:44 +08:00
[ELF][test] Reorganize some AArch64 tests Delete aarch64-got.s because it is covered by aarch64-tls-iele.s Merge got-aarch64.s into aarch64-fpic-got.s by adding disassembly to the latter Create aarch64-gnu-ifunc-nonpreemptable to unify aarch64-gnu-ifunc3.s (position-dependent executable) and aarch64-gnu-ifunc-address-pie.s (PIE) Rename aarch64-got-reloc.s to aarch64-got-weak-undef.s Add --no-show-raw-insn to llvm-objdump -d RUN lines Add -pie test to arch64-tls-iele.s Delete aarch64-tls-pie.s: it is covered by arch64-tls-iele.s and aarch64-tls-le.s Rename aarch64-copy2.s to aarch64-nopic-plt.s: "copy2" gives false impression that the test is related to copy relocation llvm-svn: 362294
2019-06-01 19:01:26 +08:00
## Local-Dynamic to Local-Exec relax creates no dynamic relocations.
# RELOC: Relocations [
# RELOC-NEXT: ]
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.
[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
# CHECK-LABEL: _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-NEXT: 2101c8: movz x0, #0, lsl #16
# CHECK-NEXT: 2101cc: movk x0, #16
# CHECK-NEXT: 2101d0: nop
# CHECK-NEXT: 2101d4: nop
Run dos2unix. NFC. llvm-svn: 263238
2016-03-11 22:34:44 +08:00
.globl _start
_start:
adrp x0, :tlsdesc:foo
ldr x1, [x0, :tlsdesc_lo12:foo]
add x0, x0, :tlsdesc_lo12:foo
.tlsdesccall foo
blr x1