[llvm-dev] Switch to ld.bfd tombstone behavior by default (original) (raw)
David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 16 18:19:51 PDT 2020
- Previous message: [llvm-dev] Upgrading LLVM's minimum required CMake version
- Next message: [llvm-dev] Switch to ld.bfd tombstone behavior by default
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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>
- Previous message: [llvm-dev] Upgrading LLVM's minimum required CMake version
- Next message: [llvm-dev] Switch to ld.bfd tombstone behavior by default
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]