[llvm-dev] Switch to ld.bfd tombstone behavior by default

[David Blaikie via llvm-dev]

In short: Perhaps we should switch lld to the bfd-style tombstoning
behavior for a release or two, letting users opt-in to testing with the new
-1/-2 tombstoning in the interim, before switching to the new tombstone by
default (while still having the flag to switch back when users find
surprise places that can't handle the new behavior).

In long:
https://reviews.llvm.org/D81784 and follow-on patches modified the behavior
of lld with regards to resolving relocations from debug sections to dead
code (either comdat deduplicated, or gc-sections use).

A very quick summary of the situation:

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:

   - -2 for DWARFv4 debug_loc, debug_ranges (-1 is a base address specifier
   there)
   - -1 elsewhere
   - linker flag to customize to other values if desired

Known issues:

   - lldb's line table parsing can't handle -1 well at all (essentially
   unusable)
   - gdb's line table parsing ends up with different handling when breaking
   on gc'd functions (minor functionality issue)
   - chromium/firefox have some tools that were broken:
   https://bugs.chromium.org/p/chromium/issues/detail?id=1102223#c5


I think there's enough risk in this work (even given the small number of
bugs found so far), given there's a pretty wide array of debug info
consumers out there, that we should change lld's default to match the
long-lived bfd strategy. This would address my original motivation for
raising all this (empty functions prematurely terminating the list), while
letting users who want to experiment with it, or need it (like Alexey), can
opt-in to the -1/-2 behavior.

I'm not sure how to get the word out to DWARF consumers that they should
consider this new experimental behavior. Ray's done a good job
evangelizing/discussing this with gdb and lldb at least - and of course
having turned it on by default briefly has found some users (like Chromium)
that we probably wouldn't have found no matter how long we left this as an
experimental option... so some things are going to break when we switch no
matter what.



P.S: Sony's already been using the -1 technique with their debugger and
linker for a while, so they may want to keep this on by default for SCE -
but I'm not sure how to do that in-tree. Clang doesn't know which lld
version it's running, so whether the flag can be specified, I would think?
(so it'd be hard to have Clang go "if SCE and LLD, pass the flag to use
-1", I think) - if there is a way to make that decision in the compiler
driver+linker, then we'd have a question of "default new behavior except
when tuning for LLDB and GDB" or "default bfd behavior except when tuning
for SCE".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200716/2d9c4bc6/attachment-0001.html>