[Dwarf-Discuss] DWARF for linker GC'd code

[David Blaikie]

Paul filed an issue covering most of the details of this issue here:
http://dwarfstd.org/ShowIssue.php?issue=200609.1

A quick summary:

non-DWARF-aware linkers (ie: that aren't parsing all the DWARF and
rewriting it during link time, which is expensive) have to resolve
relocations in DWARF that refer to functions that have been garbage
collected or deduplicated at link time. They use a few different
strategies, all with different limitations:

Original Behavior:

   - bfd: 1 for debug_ranges(0 would prematurely terminate the list), 0
   elsewhere
   - gold/lld: 0+addend everywhere

Limitations/bugs:

   - bfd/gold/lld
      -  doesn't support 0 as a valid executable address without ambiguities
   - gold/lld
      - ambiguities with large gc'd functions combined with a .text mapping
      that starts in relative low addresses
      - premature debug_range termination with zero-length functions (Clang
      produces these with __builtin_unreachable or non-void return
type functions
      without a return statement)

New behavior:

   - -1 (or "maximum value of the address representation") everywhere,
   except:
   - -2 for DWARFv4 debug_loc, debug_ranges (because -1 is a base address
   specifier there)


The trunk version of lld currently implements the new behavior with flags
to customize - but this has broken a bunch of consumers, so we're hoping to
switch to bfd's behavior (fewer limitations/bugs/issues, and more
broadly/long-term deployed/tested than the gold behavior), with a linker
flag to opt-in to the new behavior.

Do folks have any ideas about a deployment strategy for this new behavior?
Especially interested to hear from linker owners and DWARF consumers about
the sort of timelines they might be interested in adopting the new
behavior. (is this a matter of standardizing it in DWARFv6 and waiting
until DWARFv6 is on-by-default then turning it on-by-default in linkers?
Realizing that this functionality won't be able to be tied to the DWARF
version, since the linker doesn't get told the DWARF version and might be
linking DWARF spanning multiple versions - but that timeline might be long
enough to get broad adoption into consumers (it is a rather long timescale
though - I'd guess something like at least another 5 years from now,
probably longer?))

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200727/799c6d0d/attachment.html>