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

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

61 lines
2.2 KiB
ArmAsm
Raw Normal View History

[ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values See D59553, https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html and https://sourceware.org/pipermail/binutils/2020-May/111357.html for extensive discussions on a tombstone value. See http://www.dwarfstd.org/ShowIssue.php?issue=200609.1 (Reserve an address value for "not present") for a DWARF enhancement proposal. We resolve such relocations to a tombstone value to indicate that the address is invalid. This solves several problems (the normal behavior is to resolve the relocation to the addend): * For an empty function in a collected section, a pair of (0,0) can terminate .debug_loc and .debug_ranges (as of binutils 2.34, GNU ld resolves such a relocation to 1 to avoid the .debug_ranges issue) * If DW_AT_high_pc is sufficiently large, the address range can collide with a regular code range of low address (https://bugs.llvm.org/show_bug.cgi?id=41124 ) * If a text section is folded into another by ICF, we may leave entries in multiple CUs claiming ownership of the same range of code, which can confuse consumers. * Debug information associated with COMDAT sections can have problems similar to ICF, but is more complex - thus not addressed by this patch. For pre-DWARF-v5 .debug_loc and .debug_ranges, a pair of 0 can terminate entries (invalidating subsequent ranges). -1 is a reserved value with special meaning (base address selection entry) which can't be used either. Use -2 instead. For all other .debug_*, use UINT32_MAX for 32-bit targets and UINT64_MAX for 64-bit targets. In the code, we intentionally use `uint64_t tombstone = UINT64_MAX` for 32-bit targets as well: this matches SignExtend64 as used in `relocateAlloc`. (Actually UINT32_MAX does not work for R_386_32) Note 0, we only special case `target->symbolicRel` (R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64), not short-range absolute relocations (e.g. R_X86_64_32). Only forms like DW_FORM_addr need to be special cased. They can hold an arbitrary address (must be 64-bit on a 64-bit target). (In theory, producers can make use of small code model to emit 32-bit relocations. This doesn't seem to be leveraged.) Note 1, we have to ignore the addend, because we don't want to resolve DW_AT_low_pc (which may have a non-zero addend) to -1+addend (wrap around to a low address): __attribute__((section(".text.x"))) void f1() { } __attribute__((section(".text.x"))) void f2() { } // DW_AT_low_pc has a non-zero addend Note 2, if the prevailing copy does not have debugging information while a non-prevailing copy has (partial debug build), we don't do extra work to attach debugging information to the prevailing definition. (clang has a lot of debug info optimizations that are on-by-default that assume the whole program is built with debug info). clang -c -ffunction-sections a.cc # prevailing copy has no debug info clang -c -ffunction-sections -g b.cc Reviewed By: dblaikie, avl, jhenderson Differential Revision: https://reviews.llvm.org/D81784
2020-06-24 02:06:39 +08:00
# REQUIRES: x86
## Test we resolve symbolic relocations in .debug_* sections to a tombstone
## value if the referenced symbol is discarded (--gc-sections, non-prevailing
## section group, SHF_EXCLUDE, /DISCARD/, etc).
# RUN: echo '.globl _start; _start: call group' | llvm-mc -filetype=obj -triple=x86_64 - -o %t.o
# RUN: llvm-mc -filetype=obj -triple=x86_64 %s -o %t1.o
# RUN: ld.lld --gc-sections %t.o %t1.o %t1.o -o %t
# RUN: llvm-objdump -s %t | FileCheck %s
# CHECK: Contents of section .debug_loc:
[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 01000000 00000000 01000000 00000000
[ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values See D59553, https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html and https://sourceware.org/pipermail/binutils/2020-May/111357.html for extensive discussions on a tombstone value. See http://www.dwarfstd.org/ShowIssue.php?issue=200609.1 (Reserve an address value for "not present") for a DWARF enhancement proposal. We resolve such relocations to a tombstone value to indicate that the address is invalid. This solves several problems (the normal behavior is to resolve the relocation to the addend): * For an empty function in a collected section, a pair of (0,0) can terminate .debug_loc and .debug_ranges (as of binutils 2.34, GNU ld resolves such a relocation to 1 to avoid the .debug_ranges issue) * If DW_AT_high_pc is sufficiently large, the address range can collide with a regular code range of low address (https://bugs.llvm.org/show_bug.cgi?id=41124 ) * If a text section is folded into another by ICF, we may leave entries in multiple CUs claiming ownership of the same range of code, which can confuse consumers. * Debug information associated with COMDAT sections can have problems similar to ICF, but is more complex - thus not addressed by this patch. For pre-DWARF-v5 .debug_loc and .debug_ranges, a pair of 0 can terminate entries (invalidating subsequent ranges). -1 is a reserved value with special meaning (base address selection entry) which can't be used either. Use -2 instead. For all other .debug_*, use UINT32_MAX for 32-bit targets and UINT64_MAX for 64-bit targets. In the code, we intentionally use `uint64_t tombstone = UINT64_MAX` for 32-bit targets as well: this matches SignExtend64 as used in `relocateAlloc`. (Actually UINT32_MAX does not work for R_386_32) Note 0, we only special case `target->symbolicRel` (R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64), not short-range absolute relocations (e.g. R_X86_64_32). Only forms like DW_FORM_addr need to be special cased. They can hold an arbitrary address (must be 64-bit on a 64-bit target). (In theory, producers can make use of small code model to emit 32-bit relocations. This doesn't seem to be leveraged.) Note 1, we have to ignore the addend, because we don't want to resolve DW_AT_low_pc (which may have a non-zero addend) to -1+addend (wrap around to a low address): __attribute__((section(".text.x"))) void f1() { } __attribute__((section(".text.x"))) void f2() { } // DW_AT_low_pc has a non-zero addend Note 2, if the prevailing copy does not have debugging information while a non-prevailing copy has (partial debug build), we don't do extra work to attach debugging information to the prevailing definition. (clang has a lot of debug info optimizations that are on-by-default that assume the whole program is built with debug info). clang -c -ffunction-sections a.cc # prevailing copy has no debug info clang -c -ffunction-sections -g b.cc Reviewed By: dblaikie, avl, jhenderson Differential Revision: https://reviews.llvm.org/D81784
2020-06-24 02:06:39 +08:00
# CHECK-NEXT: Contents of section .debug_ranges:
[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 01000000 00000000 01000000 00000000
[ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values See D59553, https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html and https://sourceware.org/pipermail/binutils/2020-May/111357.html for extensive discussions on a tombstone value. See http://www.dwarfstd.org/ShowIssue.php?issue=200609.1 (Reserve an address value for "not present") for a DWARF enhancement proposal. We resolve such relocations to a tombstone value to indicate that the address is invalid. This solves several problems (the normal behavior is to resolve the relocation to the addend): * For an empty function in a collected section, a pair of (0,0) can terminate .debug_loc and .debug_ranges (as of binutils 2.34, GNU ld resolves such a relocation to 1 to avoid the .debug_ranges issue) * If DW_AT_high_pc is sufficiently large, the address range can collide with a regular code range of low address (https://bugs.llvm.org/show_bug.cgi?id=41124 ) * If a text section is folded into another by ICF, we may leave entries in multiple CUs claiming ownership of the same range of code, which can confuse consumers. * Debug information associated with COMDAT sections can have problems similar to ICF, but is more complex - thus not addressed by this patch. For pre-DWARF-v5 .debug_loc and .debug_ranges, a pair of 0 can terminate entries (invalidating subsequent ranges). -1 is a reserved value with special meaning (base address selection entry) which can't be used either. Use -2 instead. For all other .debug_*, use UINT32_MAX for 32-bit targets and UINT64_MAX for 64-bit targets. In the code, we intentionally use `uint64_t tombstone = UINT64_MAX` for 32-bit targets as well: this matches SignExtend64 as used in `relocateAlloc`. (Actually UINT32_MAX does not work for R_386_32) Note 0, we only special case `target->symbolicRel` (R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64), not short-range absolute relocations (e.g. R_X86_64_32). Only forms like DW_FORM_addr need to be special cased. They can hold an arbitrary address (must be 64-bit on a 64-bit target). (In theory, producers can make use of small code model to emit 32-bit relocations. This doesn't seem to be leveraged.) Note 1, we have to ignore the addend, because we don't want to resolve DW_AT_low_pc (which may have a non-zero addend) to -1+addend (wrap around to a low address): __attribute__((section(".text.x"))) void f1() { } __attribute__((section(".text.x"))) void f2() { } // DW_AT_low_pc has a non-zero addend Note 2, if the prevailing copy does not have debugging information while a non-prevailing copy has (partial debug build), we don't do extra work to attach debugging information to the prevailing definition. (clang has a lot of debug info optimizations that are on-by-default that assume the whole program is built with debug info). clang -c -ffunction-sections a.cc # prevailing copy has no debug info clang -c -ffunction-sections -g b.cc Reviewed By: dblaikie, avl, jhenderson Differential Revision: https://reviews.llvm.org/D81784
2020-06-24 02:06:39 +08:00
# CHECK-NEXT: Contents of section .debug_addr:
# CHECK-NEXT: 0000 {{.*}}000 00000000 {{.*}}000 00000000
[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: 0010 00000000 00000000 {{.*}}000 00000000
[ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values See D59553, https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html and https://sourceware.org/pipermail/binutils/2020-May/111357.html for extensive discussions on a tombstone value. See http://www.dwarfstd.org/ShowIssue.php?issue=200609.1 (Reserve an address value for "not present") for a DWARF enhancement proposal. We resolve such relocations to a tombstone value to indicate that the address is invalid. This solves several problems (the normal behavior is to resolve the relocation to the addend): * For an empty function in a collected section, a pair of (0,0) can terminate .debug_loc and .debug_ranges (as of binutils 2.34, GNU ld resolves such a relocation to 1 to avoid the .debug_ranges issue) * If DW_AT_high_pc is sufficiently large, the address range can collide with a regular code range of low address (https://bugs.llvm.org/show_bug.cgi?id=41124 ) * If a text section is folded into another by ICF, we may leave entries in multiple CUs claiming ownership of the same range of code, which can confuse consumers. * Debug information associated with COMDAT sections can have problems similar to ICF, but is more complex - thus not addressed by this patch. For pre-DWARF-v5 .debug_loc and .debug_ranges, a pair of 0 can terminate entries (invalidating subsequent ranges). -1 is a reserved value with special meaning (base address selection entry) which can't be used either. Use -2 instead. For all other .debug_*, use UINT32_MAX for 32-bit targets and UINT64_MAX for 64-bit targets. In the code, we intentionally use `uint64_t tombstone = UINT64_MAX` for 32-bit targets as well: this matches SignExtend64 as used in `relocateAlloc`. (Actually UINT32_MAX does not work for R_386_32) Note 0, we only special case `target->symbolicRel` (R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64), not short-range absolute relocations (e.g. R_X86_64_32). Only forms like DW_FORM_addr need to be special cased. They can hold an arbitrary address (must be 64-bit on a 64-bit target). (In theory, producers can make use of small code model to emit 32-bit relocations. This doesn't seem to be leveraged.) Note 1, we have to ignore the addend, because we don't want to resolve DW_AT_low_pc (which may have a non-zero addend) to -1+addend (wrap around to a low address): __attribute__((section(".text.x"))) void f1() { } __attribute__((section(".text.x"))) void f2() { } // DW_AT_low_pc has a non-zero addend Note 2, if the prevailing copy does not have debugging information while a non-prevailing copy has (partial debug build), we don't do extra work to attach debugging information to the prevailing definition. (clang has a lot of debug info optimizations that are on-by-default that assume the whole program is built with debug info). clang -c -ffunction-sections a.cc # prevailing copy has no debug info clang -c -ffunction-sections -g b.cc Reviewed By: dblaikie, avl, jhenderson Differential Revision: https://reviews.llvm.org/D81784
2020-06-24 02:06:39 +08:00
# CHECK-NEXT: Contents of section .debug_foo:
[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 00000000 08000000 00000000
# CHECK-NEXT: 0010 00000000 00000000 08000000 00000000
[ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values See D59553, https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html and https://sourceware.org/pipermail/binutils/2020-May/111357.html for extensive discussions on a tombstone value. See http://www.dwarfstd.org/ShowIssue.php?issue=200609.1 (Reserve an address value for "not present") for a DWARF enhancement proposal. We resolve such relocations to a tombstone value to indicate that the address is invalid. This solves several problems (the normal behavior is to resolve the relocation to the addend): * For an empty function in a collected section, a pair of (0,0) can terminate .debug_loc and .debug_ranges (as of binutils 2.34, GNU ld resolves such a relocation to 1 to avoid the .debug_ranges issue) * If DW_AT_high_pc is sufficiently large, the address range can collide with a regular code range of low address (https://bugs.llvm.org/show_bug.cgi?id=41124 ) * If a text section is folded into another by ICF, we may leave entries in multiple CUs claiming ownership of the same range of code, which can confuse consumers. * Debug information associated with COMDAT sections can have problems similar to ICF, but is more complex - thus not addressed by this patch. For pre-DWARF-v5 .debug_loc and .debug_ranges, a pair of 0 can terminate entries (invalidating subsequent ranges). -1 is a reserved value with special meaning (base address selection entry) which can't be used either. Use -2 instead. For all other .debug_*, use UINT32_MAX for 32-bit targets and UINT64_MAX for 64-bit targets. In the code, we intentionally use `uint64_t tombstone = UINT64_MAX` for 32-bit targets as well: this matches SignExtend64 as used in `relocateAlloc`. (Actually UINT32_MAX does not work for R_386_32) Note 0, we only special case `target->symbolicRel` (R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64), not short-range absolute relocations (e.g. R_X86_64_32). Only forms like DW_FORM_addr need to be special cased. They can hold an arbitrary address (must be 64-bit on a 64-bit target). (In theory, producers can make use of small code model to emit 32-bit relocations. This doesn't seem to be leveraged.) Note 1, we have to ignore the addend, because we don't want to resolve DW_AT_low_pc (which may have a non-zero addend) to -1+addend (wrap around to a low address): __attribute__((section(".text.x"))) void f1() { } __attribute__((section(".text.x"))) void f2() { } // DW_AT_low_pc has a non-zero addend Note 2, if the prevailing copy does not have debugging information while a non-prevailing copy has (partial debug build), we don't do extra work to attach debugging information to the prevailing definition. (clang has a lot of debug info optimizations that are on-by-default that assume the whole program is built with debug info). clang -c -ffunction-sections a.cc # prevailing copy has no debug info clang -c -ffunction-sections -g b.cc Reviewed By: dblaikie, avl, jhenderson Differential Revision: https://reviews.llvm.org/D81784
2020-06-24 02:06:39 +08:00
[ELF] Add -z dead-reloc-in-nonalloc=<section_glob>=<value> ... to customize the tombstone value we use for an absolute relocation referencing a discarded symbol. This can be used as a workaround when some debug processing tool has trouble with current -1 tombstone value (https://bugs.chromium.org/p/chromium/issues/detail?id=1102223#c11 ) For example, to get the current built-in rules (not considering the .debug_line special case for ICF): ``` -z dead-reloc-in-nonalloc='.debug_*=0xffffffffffffffff' -z dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe -z dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe ``` To get GNU ld (as of binutils 2.35)'s behavior: ``` -z dead-reloc-in-nonalloc='*=0' -z dead-reloc-in-nonalloc=.debug_ranges=1 ``` This option has other use cases. For example, if we want to check whether a non-SHF_ALLOC section has dead relocations. With this patch, we can run a regular LLD and run another with a special -z dead-reloc-in-nonalloc=, then compare their output. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D83264
2020-07-09 01:10:43 +08:00
## -z dead-reloc-in-nonalloc= can override the tombstone value.
# RUN: ld.lld --gc-sections -z dead-reloc-in-nonalloc=.debug_loc=42 %t.o %t1.o %t1.o -o %t42
# RUN: llvm-objdump -s %t42 | FileCheck %s --check-prefix=OVERRIDE
# OVERRIDE: Contents of section .debug_loc:
# OVERRIDE-NEXT: 0000 2a000000 00000000 2a000000 00000000
[ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values See D59553, https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html and https://sourceware.org/pipermail/binutils/2020-May/111357.html for extensive discussions on a tombstone value. See http://www.dwarfstd.org/ShowIssue.php?issue=200609.1 (Reserve an address value for "not present") for a DWARF enhancement proposal. We resolve such relocations to a tombstone value to indicate that the address is invalid. This solves several problems (the normal behavior is to resolve the relocation to the addend): * For an empty function in a collected section, a pair of (0,0) can terminate .debug_loc and .debug_ranges (as of binutils 2.34, GNU ld resolves such a relocation to 1 to avoid the .debug_ranges issue) * If DW_AT_high_pc is sufficiently large, the address range can collide with a regular code range of low address (https://bugs.llvm.org/show_bug.cgi?id=41124 ) * If a text section is folded into another by ICF, we may leave entries in multiple CUs claiming ownership of the same range of code, which can confuse consumers. * Debug information associated with COMDAT sections can have problems similar to ICF, but is more complex - thus not addressed by this patch. For pre-DWARF-v5 .debug_loc and .debug_ranges, a pair of 0 can terminate entries (invalidating subsequent ranges). -1 is a reserved value with special meaning (base address selection entry) which can't be used either. Use -2 instead. For all other .debug_*, use UINT32_MAX for 32-bit targets and UINT64_MAX for 64-bit targets. In the code, we intentionally use `uint64_t tombstone = UINT64_MAX` for 32-bit targets as well: this matches SignExtend64 as used in `relocateAlloc`. (Actually UINT32_MAX does not work for R_386_32) Note 0, we only special case `target->symbolicRel` (R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64), not short-range absolute relocations (e.g. R_X86_64_32). Only forms like DW_FORM_addr need to be special cased. They can hold an arbitrary address (must be 64-bit on a 64-bit target). (In theory, producers can make use of small code model to emit 32-bit relocations. This doesn't seem to be leveraged.) Note 1, we have to ignore the addend, because we don't want to resolve DW_AT_low_pc (which may have a non-zero addend) to -1+addend (wrap around to a low address): __attribute__((section(".text.x"))) void f1() { } __attribute__((section(".text.x"))) void f2() { } // DW_AT_low_pc has a non-zero addend Note 2, if the prevailing copy does not have debugging information while a non-prevailing copy has (partial debug build), we don't do extra work to attach debugging information to the prevailing definition. (clang has a lot of debug info optimizations that are on-by-default that assume the whole program is built with debug info). clang -c -ffunction-sections a.cc # prevailing copy has no debug info clang -c -ffunction-sections -g b.cc Reviewed By: dblaikie, avl, jhenderson Differential Revision: https://reviews.llvm.org/D81784
2020-06-24 02:06:39 +08:00
.section .text.1,"ax"
.byte 0
.section .text.2,"axe"
.byte 0
.section .text.3,"axG",@progbits,group,comdat
.globl group
group:
.byte 0
[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
## Resolved to UINT64_C(1), with the addend ignored.
[ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values See D59553, https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html and https://sourceware.org/pipermail/binutils/2020-May/111357.html for extensive discussions on a tombstone value. See http://www.dwarfstd.org/ShowIssue.php?issue=200609.1 (Reserve an address value for "not present") for a DWARF enhancement proposal. We resolve such relocations to a tombstone value to indicate that the address is invalid. This solves several problems (the normal behavior is to resolve the relocation to the addend): * For an empty function in a collected section, a pair of (0,0) can terminate .debug_loc and .debug_ranges (as of binutils 2.34, GNU ld resolves such a relocation to 1 to avoid the .debug_ranges issue) * If DW_AT_high_pc is sufficiently large, the address range can collide with a regular code range of low address (https://bugs.llvm.org/show_bug.cgi?id=41124 ) * If a text section is folded into another by ICF, we may leave entries in multiple CUs claiming ownership of the same range of code, which can confuse consumers. * Debug information associated with COMDAT sections can have problems similar to ICF, but is more complex - thus not addressed by this patch. For pre-DWARF-v5 .debug_loc and .debug_ranges, a pair of 0 can terminate entries (invalidating subsequent ranges). -1 is a reserved value with special meaning (base address selection entry) which can't be used either. Use -2 instead. For all other .debug_*, use UINT32_MAX for 32-bit targets and UINT64_MAX for 64-bit targets. In the code, we intentionally use `uint64_t tombstone = UINT64_MAX` for 32-bit targets as well: this matches SignExtend64 as used in `relocateAlloc`. (Actually UINT32_MAX does not work for R_386_32) Note 0, we only special case `target->symbolicRel` (R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64), not short-range absolute relocations (e.g. R_X86_64_32). Only forms like DW_FORM_addr need to be special cased. They can hold an arbitrary address (must be 64-bit on a 64-bit target). (In theory, producers can make use of small code model to emit 32-bit relocations. This doesn't seem to be leveraged.) Note 1, we have to ignore the addend, because we don't want to resolve DW_AT_low_pc (which may have a non-zero addend) to -1+addend (wrap around to a low address): __attribute__((section(".text.x"))) void f1() { } __attribute__((section(".text.x"))) void f2() { } // DW_AT_low_pc has a non-zero addend Note 2, if the prevailing copy does not have debugging information while a non-prevailing copy has (partial debug build), we don't do extra work to attach debugging information to the prevailing definition. (clang has a lot of debug info optimizations that are on-by-default that assume the whole program is built with debug info). clang -c -ffunction-sections a.cc # prevailing copy has no debug info clang -c -ffunction-sections -g b.cc Reviewed By: dblaikie, avl, jhenderson Differential Revision: https://reviews.llvm.org/D81784
2020-06-24 02:06:39 +08:00
## UINT64_C(-1) is a reserved value (base address selection entry) which can't be used.
.section .debug_loc
.quad .text.1+8
.section .debug_ranges
.quad .text.2+16
.section .debug_addr
## .text.3 is a local symbol. The symbol defined in a non-prevailing group is
[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
## discarded. Resolved to UINT64_C(0).
[ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values See D59553, https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html and https://sourceware.org/pipermail/binutils/2020-May/111357.html for extensive discussions on a tombstone value. See http://www.dwarfstd.org/ShowIssue.php?issue=200609.1 (Reserve an address value for "not present") for a DWARF enhancement proposal. We resolve such relocations to a tombstone value to indicate that the address is invalid. This solves several problems (the normal behavior is to resolve the relocation to the addend): * For an empty function in a collected section, a pair of (0,0) can terminate .debug_loc and .debug_ranges (as of binutils 2.34, GNU ld resolves such a relocation to 1 to avoid the .debug_ranges issue) * If DW_AT_high_pc is sufficiently large, the address range can collide with a regular code range of low address (https://bugs.llvm.org/show_bug.cgi?id=41124 ) * If a text section is folded into another by ICF, we may leave entries in multiple CUs claiming ownership of the same range of code, which can confuse consumers. * Debug information associated with COMDAT sections can have problems similar to ICF, but is more complex - thus not addressed by this patch. For pre-DWARF-v5 .debug_loc and .debug_ranges, a pair of 0 can terminate entries (invalidating subsequent ranges). -1 is a reserved value with special meaning (base address selection entry) which can't be used either. Use -2 instead. For all other .debug_*, use UINT32_MAX for 32-bit targets and UINT64_MAX for 64-bit targets. In the code, we intentionally use `uint64_t tombstone = UINT64_MAX` for 32-bit targets as well: this matches SignExtend64 as used in `relocateAlloc`. (Actually UINT32_MAX does not work for R_386_32) Note 0, we only special case `target->symbolicRel` (R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64), not short-range absolute relocations (e.g. R_X86_64_32). Only forms like DW_FORM_addr need to be special cased. They can hold an arbitrary address (must be 64-bit on a 64-bit target). (In theory, producers can make use of small code model to emit 32-bit relocations. This doesn't seem to be leveraged.) Note 1, we have to ignore the addend, because we don't want to resolve DW_AT_low_pc (which may have a non-zero addend) to -1+addend (wrap around to a low address): __attribute__((section(".text.x"))) void f1() { } __attribute__((section(".text.x"))) void f2() { } // DW_AT_low_pc has a non-zero addend Note 2, if the prevailing copy does not have debugging information while a non-prevailing copy has (partial debug build), we don't do extra work to attach debugging information to the prevailing definition. (clang has a lot of debug info optimizations that are on-by-default that assume the whole program is built with debug info). clang -c -ffunction-sections a.cc # prevailing copy has no debug info clang -c -ffunction-sections -g b.cc Reviewed By: dblaikie, avl, jhenderson Differential Revision: https://reviews.llvm.org/D81784
2020-06-24 02:06:39 +08:00
.quad .text.3+24
## group is a non-local symbol. The relocation from the second %t1.o gets
## resolved to the prevailing copy.
.quad group+32
.section .debug_foo
.quad .text.1+8
## We only deal with DW_FORM_addr. Don't special case short-range absolute
## relocations. Treat them like regular absolute relocations referencing
## discarded symbols, which are resolved to the addend.
.long .text.1+8
.long 0