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/debug-dead-reloc-tls-arm.s

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

23 lines
534 B
ArmAsm
Raw Normal View History

[ELF] Resolve R_DTPREL in .debug_* referencing discarded symbols to -1 The location of a TLS variable is encoded as a DW_OP_const4u/DW_OP_const8u followed by a DW_OP_push_tls_address (or DW_OP_GNU_push_tls_address https://sourceware.org/bugzilla/show_bug.cgi?id=11616 ). This change follows up to D81784 and makes relocations types generalized as R_DTPREL (e.g. R_X86_64_DTPOFF{32,64}, R_PPC64_DTPREL64) use -1 as the tombstone value as well. This works for both TLS Variant I and Variant II architectures. * arm: .long tls(tlsldo) # not working currently (R_ARM_TLS_LDO32 is R_ABS) * mips64: .dtpreldword tls+32768 * ppc64: .quad tls@DTPREL+0x8000 * riscv: neither GCC nor clang has implemented DW_AT_location. It is likely .long/.quad tls@dtprel+0x800 * x86-32: .long tls@DTPOFF * x86-64: .long tls@DTPOFF; .quad tls@DTPOFF tls has a non-negative st_value, so such relocations (st_value+addend) never resolve to -1 in a normal (not discarded) case. ``` // clang -fuse-ld=lld -g -ffunction-sections a.c -Wl,--gc-sections // foo and tls will be discarded by --gc-sections. // DW_AT_location [DW_FORM_exprloc] (DW_OP_const8u 0xffffffffffffffff, DW_OP_GNU_push_tls_address) thread_local int tls; int foo() { return ++tls; } int main() {} ``` Also, drop logic added in D26201 intended to address PR30793. It added a test (gc-debuginfo-tls.s) using a non-SHF_ALLOC section and a local symbol, which does not reflect the intended scenario: a relocation in a SHF_ALLOC section referencing a discarded non-local symbol. For such a non .debug_* section, just emit an error. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D82899
2020-07-04 00:50:30 +08:00
# REQUIRES: arm
## Test we resolve relocations referencing TLS symbols in .debug_* sections to
## a tombstone value if the referenced TLS symbol is discarded.
# RUN: llvm-mc -filetype=obj -triple=armv7a-none-linux-gnueabi %s -o %t.o
# RUN: ld.lld --gc-sections %t.o -o %t
# RUN: llvm-objdump -s %t | FileCheck %s
# CHECK: Contents of section .debug_info:
[ELF] Change tombstone values to (.debug_ranges/.debug_loc) 1 and (other .debug_*) 0 tl;dr See D81784 for the 'tombstone value' concept. This patch changes our behavior to be almost the same as GNU ld (except that we also use 1 for .debug_loc): * .debug_ranges & .debug_loc: 1 (LLD<11: 0+addend; GNU ld uses 1 for .debug_ranges) * .debug_*: 0 (LLD<11: 0+addend; GNU ld uses 0; future LLD: -1) We make the tweaks because: 1) The new tombstone is novel and needs more time to be adopted by consumers before it's the default. 2) The old (gold) strategy had problems with zero-length functions - so rather than going back that, we're going to the GNU ld strategy which doesn't have that problem. 3) One slight tweak to (2) is to apply the .debug_ranges workaround to .debug_loc for the same reasons it applies to debug_ranges - to avoid terminating lists early. ----- http://lists.llvm.org/pipermail/llvm-dev/2020-July/143482.html The tombstone value -1 in .debug_line caused problems to lldb (fixed by D83957; will be included in 11.0.0) and breakpad (fixed by https://crrev.com/c/2321300). It may potentially affects other DWARF consumers. For .debug_ranges & .debug_loc: 1, an argument preferring 1 (GNU ld for .debug_ranges) over -2 is that: ``` {-1, -2} <<< base address selection entry {0, length} <<< address range ``` may create a situation where low_pc is greater than high_pc. So we use 1, the GNU ld behavior for .debug_ranges For other .debug_* sections, there haven't been many reports. One issue is that bloaty (src/dwarf.cc) can incorrectly count address ranges in .debug_ranges . To reduce similar disruption, this patch changes the tombstone values to be similar to GNU ld. This does mean another behavior change to the default trunk behavior. Sorry about it. The default trunk behavior will be similar to release/11.x while we work on a transition plan for LLD users. Reviewed By: dblaikie, echristo Differential Revision: https://reviews.llvm.org/D84825
2020-08-07 03:34:16 +08:00
# CHECK-NEXT: 0000 00000000
[ELF] Resolve R_DTPREL in .debug_* referencing discarded symbols to -1 The location of a TLS variable is encoded as a DW_OP_const4u/DW_OP_const8u followed by a DW_OP_push_tls_address (or DW_OP_GNU_push_tls_address https://sourceware.org/bugzilla/show_bug.cgi?id=11616 ). This change follows up to D81784 and makes relocations types generalized as R_DTPREL (e.g. R_X86_64_DTPOFF{32,64}, R_PPC64_DTPREL64) use -1 as the tombstone value as well. This works for both TLS Variant I and Variant II architectures. * arm: .long tls(tlsldo) # not working currently (R_ARM_TLS_LDO32 is R_ABS) * mips64: .dtpreldword tls+32768 * ppc64: .quad tls@DTPREL+0x8000 * riscv: neither GCC nor clang has implemented DW_AT_location. It is likely .long/.quad tls@dtprel+0x800 * x86-32: .long tls@DTPOFF * x86-64: .long tls@DTPOFF; .quad tls@DTPOFF tls has a non-negative st_value, so such relocations (st_value+addend) never resolve to -1 in a normal (not discarded) case. ``` // clang -fuse-ld=lld -g -ffunction-sections a.c -Wl,--gc-sections // foo and tls will be discarded by --gc-sections. // DW_AT_location [DW_FORM_exprloc] (DW_OP_const8u 0xffffffffffffffff, DW_OP_GNU_push_tls_address) thread_local int tls; int foo() { return ++tls; } int main() {} ``` Also, drop logic added in D26201 intended to address PR30793. It added a test (gc-debuginfo-tls.s) using a non-SHF_ALLOC section and a local symbol, which does not reflect the intended scenario: a relocation in a SHF_ALLOC section referencing a discarded non-local symbol. For such a non .debug_* section, just emit an error. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D82899
2020-07-04 00:50:30 +08:00
.globl _start
_start:
bx lr
.section .tbss,"awT",%nobits
.globl tls
.long 0
.section .debug_info
## R_ARM_TLS_LDO32
.long tls(tlsldo)