[PATCH] D107076: [DWARF] Revert sharing subprograms across CUs
Jeremy Morse via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 29 07:25:56 PDT 2021
jmorse created this revision.
jmorse added reviewers: aprantl, vsk, dblaikie, probinson.
Herald added subscribers: ormris, steven_wu, hiraditya.
jmorse requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.
Over in D70350 <https://reviews.llvm.org/D70350>, DW_TAG_subprograms were permitted to be referenced across CU boundaries, to improve stack trace construction using call site information. Unfortunately, as documented in PR48790 [0], the way that subprograms are "owned" by dwarf units is sufficiently complicated that subprograms end up in unexpected units, invalidating cross-unit references.
I tried to fix this in D94976 <https://reviews.llvm.org/D94976>, however it uncovered additional problems with unit ownership of subprograms. @kyulee reports running into illegal DWARF references too, thus we're left with the choices of:
- Knowingly emitting illegal DWARF in certain circumstances,
- Damaging stack traces in certain circumstances.
Of which I would pick the latter: it's better to sometimes have a worse debugging experience, than to have scenarios where debugging is completely impossible. Opinions may vary; feedback most appreciated, especially @vsk @aprantl who'll suffer the backtrace damage. The intention is to cherry-pick this into llvm-13 too.
This patch is a revert of e08f205f5c2c <https://reviews.llvm.org/rGe08f205f5c2cfdbec64ccd97f0ac271d17a1ba93>, with some light conflicts around the declaration of constructCallSiteEntryDIE, nothing especially interesting. Three tests change in addition to the reversion:
- dbgcall-site-indirect-param.mir , has an additional function and DW_TAG_formal_parameter placed ahead of the targeted function in dwarfdump output,
- callsite-stack-value.mir , same problem as dbgcall-site-indirect-param.mir
- convert-loclist.ll : the DWO_id number changes, which I don't think is a suprise.
In addition I've added subprogram-across-cus.ll from D94976 <https://reviews.llvm.org/D94976> as a regression test, it compiles some IR and then runs llvm-dwarfdump -verify on it.
[0] https://bugs.llvm.org/show_bug.cgi?id=48790
Repository:
rG LLVM Github Monorepo
https://reviews.llvm.org/D107076
Files:
llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.h
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h
llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
llvm/test/DebugInfo/AArch64/unretained-declaration-subprogram.ll
llvm/test/DebugInfo/MIR/AArch64/dbgcall-site-indirect-param.mir
llvm/test/DebugInfo/MIR/AArch64/dbgcall-site-orr-moves.mir
llvm/test/DebugInfo/MIR/X86/callsite-stack-value.mir
llvm/test/DebugInfo/MIR/X86/debug-call-site-param.mir
llvm/test/DebugInfo/X86/convert-loclist.ll
llvm/test/DebugInfo/X86/fission-call-site.ll
llvm/test/DebugInfo/X86/lto-cross-cu-call-origin-ref.ll
llvm/test/DebugInfo/X86/subprogram-across-cus.ll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D107076.362763.patch
Type: text/x-patch
Size: 32968 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210729/ba2a7231/attachment.bin>
More information about the llvm-commits
mailing list