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-tlsld-ldst.s

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

86 lines
2.6 KiB
ArmAsm
Raw Normal View History

[ELF] Move `// REQUIRES:` line to the top llvm-svn: 335676
2018-06-27 06:20:04 +08:00
// REQUIRES: aarch64
[ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs Implement the following relocations for AArch64: R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC These are specified in ELF for the 64-bit Arm Architecture. Fixes pr36727 Differential Revision: https://reviews.llvm.org/D46255 llvm-svn: 331511
2018-05-04 16:53:34 +08:00
// RUN: llvm-mc -triple=aarch64-linux-gnu -filetype=obj %s -o %t.o
// RUN: ld.lld %t.o -o %t
[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 %t | FileCheck %s
[ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs Implement the following relocations for AArch64: R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC These are specified in ELF for the 64-bit Arm Architecture. Fixes pr36727 Differential Revision: https://reviews.llvm.org/D46255 llvm-svn: 331511
2018-05-04 16:53:34 +08:00
// RUN: llvm-readelf --symbols %t | FileCheck -check-prefix CHECK-SYMS %s
[ELF][AArch64] Add REQUIRES aarch64 to test [NFC] Forgot to add REQUIRES aarch64 to the test I recently added for D46255. llvm-svn: 331513
2018-05-04 17:10:18 +08:00
[ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs Implement the following relocations for AArch64: R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC These are specified in ELF for the 64-bit Arm Architecture. Fixes pr36727 Differential Revision: https://reviews.llvm.org/D46255 llvm-svn: 331511
2018-05-04 16:53:34 +08:00
.text
.globl _start
.type _start, %function
_start: mrs x8, TPIDR_EL0
add x8, x8, :tprel_hi12:var0
ldr q20, [x8, :tprel_lo12_nc:var0]
add x8, x8, :tprel_hi12:var1
ldr x0, [x8, :tprel_lo12_nc:var1]
add x8, x8, :tprel_hi12:var2
ldr w0, [x8, :tprel_lo12_nc:var2]
add x8, x8, :tprel_hi12:var3
ldrh w0, [x8, :tprel_lo12_nc:var3]
add x8, x8, :tprel_hi12:var4
ldrb w0, [x8, :tprel_lo12_nc:var4]
[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-NEXT: 210158: mrs x8, TPIDR_EL0
[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
// 0x0 + c10 = 0xc10 = tcb (16-bytes) + var0
[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: 21015c: add x8, x8, #0, lsl #12
// CHECK-NEXT: 210160: ldr q20, [x8, #3088]
[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
// 0x1000 + 0x820 = 0x1820 = tcb + var1
[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: 210164: add x8, x8, #1, lsl #12
// CHECK-NEXT: 210168: ldr x0, [x8, #2080]
[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
// 0x2000 + 0x428 = 0x2428 = tcb + var2
[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: 21016c: add x8, x8, #2, lsl #12
// CHECK-NEXT: 210170: ldr w0, [x8, #1064]
[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
// 0x3000 + 0x2c = 0x302c = tcb + var3
[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: 210174: add x8, x8, #3, lsl #12
// CHECK-NEXT: 210178: ldrh w0, [x8, #44]
[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
// 0x3000 + 0xc2e = 0x32ce = tcb + var4
[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: 21017c: add x8, x8, #3, lsl #12
// CHECK-NEXT: 210180: ldrb w0, [x8, #3118]
[ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs Implement the following relocations for AArch64: R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC These are specified in ELF for the 64-bit Arm Architecture. Fixes pr36727 Differential Revision: https://reviews.llvm.org/D46255 llvm-svn: 331511
2018-05-04 16:53:34 +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
// CHECK-SYMS: 0000000000000c00 0 TLS GLOBAL DEFAULT 2 var0
// CHECK-SYMS-NEXT: 0000000000001810 4 TLS GLOBAL DEFAULT 2 var1
// CHECK-SYMS-NEXT: 0000000000002418 2 TLS GLOBAL DEFAULT 2 var2
// CHECK-SYMS-NEXT: 000000000000301c 1 TLS GLOBAL DEFAULT 2 var3
// CHECK-SYMS-NEXT: 0000000000003c1e 0 TLS GLOBAL DEFAULT 2 var4
[ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs Implement the following relocations for AArch64: R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC These are specified in ELF for the 64-bit Arm Architecture. Fixes pr36727 Differential Revision: https://reviews.llvm.org/D46255 llvm-svn: 331511
2018-05-04 16:53:34 +08:00
.globl var0
.globl var1
.globl var2
.globl var3
.globl var4
.type var0,@object
.type var1,@object
.type var2,@object
.type var3,@object
.section .tbss,"awT",@nobits
[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
.balign 16
[ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs Implement the following relocations for AArch64: R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC These are specified in ELF for the 64-bit Arm Architecture. Fixes pr36727 Differential Revision: https://reviews.llvm.org/D46255 llvm-svn: 331511
2018-05-04 16:53:34 +08:00
.space 1024 * 3
var0:
.quad 0
.quad 0
[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
.size var1, 16
[ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs Implement the following relocations for AArch64: R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC These are specified in ELF for the 64-bit Arm Architecture. Fixes pr36727 Differential Revision: https://reviews.llvm.org/D46255 llvm-svn: 331511
2018-05-04 16:53:34 +08:00
.space 1024 * 3
var1:
.quad 0
.size var1, 8
.space 1024 * 3
var2:
.word 0
[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
.size var1, 4
[ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs Implement the following relocations for AArch64: R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC These are specified in ELF for the 64-bit Arm Architecture. Fixes pr36727 Differential Revision: https://reviews.llvm.org/D46255 llvm-svn: 331511
2018-05-04 16:53:34 +08:00
.space 1024 * 3
var3:
.hword 0
[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
.size var2, 2
[ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs Implement the following relocations for AArch64: R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC These are specified in ELF for the 64-bit Arm Architecture. Fixes pr36727 Differential Revision: https://reviews.llvm.org/D46255 llvm-svn: 331511
2018-05-04 16:53:34 +08:00
.space 1024 * 3
var4:
.byte 0
[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
.size var3, 1
[ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs Implement the following relocations for AArch64: R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC These are specified in ELF for the 64-bit Arm Architecture. Fixes pr36727 Differential Revision: https://reviews.llvm.org/D46255 llvm-svn: 331511
2018-05-04 16:53:34 +08:00
.space 1024 * 3