Over in 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, 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, 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 as a regression test, it compiles some IR and then runs llvm-dwarfdump -verify on it.