This is a fix for PR48790 . Over in D70350, subprogram DIEs were permitted to be shared between CUs. However, as documented in the PR the creation of a subprogram DIE can be triggered early, from other CUs. The subprogram definition is then placed in that other CU incorrectly, breaking internal CU references attached to the subprogram later by things expecting it to be in the correct CU.
To fix this, I've added an extra test to DwarfUnit::getOrCreateSubprogramDIE that examines the "unit" field of the DISubprogram being created. If it isn't the current CU, the correct one is looked up and creation passed to that CU. The test also accepts being placed in the skeleton CU in split DWARF, happily there are a few tests looking for that.
This should (TM) prevent subprogram DIEs being placed in the wrong unit, but I have two worries:
- I believe all subprograms definitions get units added to them, but could a declaration DISubprogram passed to DwarfUnit::getOrCreateSubprogramDIE with no unit lead to the same problem?
- We assume that all call-sites attempting to create a subprogram DIE are prepared to handle a cross-CU reference (which is what this patch will start producing), which as we've seen in , isn't necessarily true.
I've also made DwarfCompileUnits lookable-uppable with a DICompileUnit by publishing getOrCreateDwarfCompileUnit. I don't think there's any other way around creating a DIE in a different unit without doing this.
Test added is the reproducer from , gets run through llvm-dwarfdump -verify and has its output examined to ensure "eee" is in the CU for 2.cpp.