[PATCH] D81784: [ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jun 13 00:30:43 PDT 2020


MaskRay created this revision.
Herald added subscribers: llvm-commits, arichardson, aprantl, emaste.
Herald added a reviewer: espindola.
Herald added a project: LLVM.

See D59553 <https://reviews.llvm.org/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.  -1 is a reserved value with special meaning (base address
selection entry) with. 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 as well: this matches
SignExtend64 as used in `relocateAlloc`.

Note, 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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D81784

Files:
  lld/ELF/InputSection.cpp
  lld/test/ELF/debug-dead-reloc-32.s
  lld/test/ELF/debug-dead-reloc-icf.s
  lld/test/ELF/debug-dead-reloc.s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D81784.270566.patch
Type: text/x-patch
Size: 6257 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200613/9484dffa/attachment.bin>


More information about the llvm-commits mailing list