[DebugInfo] Keep the CU consistent for operating `DISubprogram`.

[DianQK]

Summary

Fixes 61932.

The core issue I found is that DISubprogram operations usually use getUnit, while its DIE uses getScope. Once these two are associated with different CUs, associated DIEs may use another CU.

I found that even under llc version 15.0.7, DW_AT_low_pc and DW_AT_high_pc are still placed under the wrong CU. The D136039 just reflected this error to other locations. And this "Cannot represent a difference across sections" error only occurs on x86/x86-64.

$ llc -O0 -mtriple=x86_64-unknown-unknown -filetype=obj test.ll
$ llvm-dwarfdump --debug-info --verbose test.o
0x0000000b: DW_TAG_compile_unit [1] *
...
              DW_AT_low_pc [DW_FORM_addr]	(0x0000000000000070 ".text")
              DW_AT_high_pc [DW_FORM_data4]	(0x00000000)
0x00000080:     DW_TAG_namespace [5] * (0x0000004b)
...
0x00000085:       DW_TAG_structure_type [6] * (0x00000080)
...
0x0000008c:         DW_TAG_subprogram [9] * (0x00000085)
                      DW_AT_low_pc [DW_FORM_addr]	(0x0000000000000000 ".text")
                      DW_AT_high_pc [DW_FORM_data4]	(0x00000062)
...
0x000000a5:           DW_TAG_lexical_block [10] * (0x0000008c)
                        DW_AT_low_pc [DW_FORM_addr]	(0x0000000000000030 ".text")
                        DW_AT_high_pc [DW_FORM_data4]	(0x0000001e)
...

0x000000fe: DW_TAG_compile_unit [1] *
...
              DW_AT_low_pc [DW_FORM_addr]	(0x0000000000000000 ".text") <--- This should be in another CU.
              DW_AT_high_pc [DW_FORM_data4]	(0x00000062) <--- This should be in another CU.
...

[DianQK]

Eliminate duplicate code and update tests.

[dblaikie]

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1275–1278

Could you explain more about when/how/why these are ever different CUs? (when would the scope have a different CU from the subprogram itself)

[dblaikie]

The use of getScope seems to be the buggy part, maybe - it should be getting the scope from the appropriate CU and it isn't, maybe?

Also the LLVM UIR in the test case seems strange to me - I guess you've put DISubprogram dedfinitions scoped within the type declaration? That isn't usually how we do things & might lead to problems with debuggers since this may be unexpected. (GCC always puts the definitions at the global scope, clang puts the definitions at namespace scope I think - though perhaps at the global scope when there's a member function declaration anyway) Maybe that's part of the problem? (the scoping of the definitions - that it's not how LLVM ddebug info IR is usually generated by clang, so you may benefit from doing something more clang-like on the rust side to avoid running into more untested/unsupported cases)

Especially when it comes to type units and things, I can imagine this sort of IR might hit a lot of untested corners.

[nikic]

In D147620#4279004, @dblaikie wrote:

Also the LLVM UIR in the test case seems strange to me - I guess you've put DISubprogram dedfinitions scoped within the type declaration?

I looked around a bit, and I think the answer is yes based on this comment: https://github.com/rust-lang/rust/blob/c7815840793b980d0aae7d5a2f5d9bb1fd6c0d1e/compiler/rustc_codegen_llvm/src/debuginfo/mod.rs#L502-L504 Looking through blame, this was implemented in https://github.com/rust-lang/rust/pull/33358 to fix https://github.com/rust-lang/rust/issues/33192. I don't know anything about DWARF, so can't comment on whether that was the right/wrong solution.

[DianQK]

In D147620#4279004, @dblaikie wrote:

Also the LLVM UIR in the test case seems strange to me.

I read 2.3 Relationship of Debugging Information Entries in DWARF5. There don't seem to be any constraints on the relationship of DIEs. So I guess the structure of this debugging info is at least reasonably present?
I do not know Rust and Swift's debugging information generation. But these languages all seem to generate similar debugging message structures. Maybe having LTO could improve the structure here?

Alternatively, we can use this patch to remove the changes to D135114 and D136039.

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1275–1278

Let's see llvm/test/DebugInfo/Generic/cross-cu.ll.
The first key point is that beginModule is executed before beginFunctionImpl.
The second key point is the creation of the global at beginModule.

Follow the creation chain of Global:

1. !4 CU via global create !8 DIGlobalVariable
2. !4 CU in !8 DIGlobalVariable via type create !10 DICompositeType
3. !4 CU in !10 via vtableHolder create !11
4. !4 CU in !11 via baseType create !12
5. !4 CU in !12 via elements create !15=!{!16}
6. !4 CU in !16 via baseType create !17
7. !4 CU in !17 via templateParams create !19=!{!20}
8. !4 CU in !20 via type create !21

Now !21 belongs to !4!
But the !23 is distinct !DISubprogram(name: "alloc_impl", scope: !21, unit: !1).

The previous llvm/test/DebugInfo/Generic/cross-cu-inlining-2.ll and llvm/test/DebugInfo/Generic/cross-cu-inlining-ranges.ll were in a similar case.

[DianQK]

Remove updateSubprogramScopeDIE.

[DianQK]

Rebase.

[dblaikie]

llvm/test/DebugInfo/Generic/cross-cu.ll

40–62

OK, so from the description in the other inline comment - I take it you're dealing with the situation here, where:

!23 (DISubprogram for alloc::alloc::Global::alloc_impl) is defined in CU !1
!8 that also, indirectly, references the type is in CU !4

Yeah, I think the bug here is that you shouldn't have member function definitions directly associated with DICompositeTypes - they should indirect through a declaration of the function.

Otherwise we'll inevitably end up in impossible situations - where we can't define the type in every translation unit that defines one of the member functions (or other references) to the type.

Types are intentionally not attached to a CU because they exist across the whole program - so we need to be able to reference them from anywhere/lazily create them in whatever CU we need, generally.

If you've got similar metadata from Swift, I'd like to take a look/talk to the Apple/Swift folks about this.

But, yeah, generally, I don't think this IR is OK/supportable as-is. It should have a declaration of the function - so that the function definition can appear in a CU distinct from the definition of the type. So the function definition can stay in the CU that defined it.

[DianQK]

llvm/test/DebugInfo/Generic/cross-cu.ll

40–62

Thank you for clarifying the issue.
Maybe @aprantl could come and take a look at Swift?

I'm glad to check out the Rust-related implementation. I only know a little bit about Rust. It may take some time.
Do you think it is appropriate to submit this patch as a workaround? We can revert it before LLVM 17 is released.
This change does not appear to affect C++ debug info generation.

[dblaikie]

llvm/test/DebugInfo/Generic/cross-cu.ll

40–62

I don't think it's suitable to commit as a workaround - but maybe other folks have other ideas/I wouldn't rule it out entirely.

If you're not especially familiar with Rust, what's your particular context for/interest in this bug?

[DianQK]

llvm/test/DebugInfo/Generic/cross-cu.ll

40–62

I don't think it's suitable to commit as a workaround - but maybe other folks have other ideas/I wouldn't rule it out entirely.

If we treat all such IR fixes as a workaround, I realize that D136039 is a vulnerable workaround. It corrects one CU and affects the CU of another case. But this issue does not occur with the current patch.
I have found that inconsistent CU can lead to several problems:

• Invalid DWARF: no mapping for range, inconsistent range data, and could not find referenced DIE.
• Unable to generate target file: Cannot represent a difference across sections.

After this patch, we will get Valid but useless DWARF. I think Valid but useless DWARF is better than Invalid DWARF, and Invalid DWARF is better than Unable to generate target file in these three bad cases. We can make a no-good IR work as well as possible. Here's what I think.

But it may also be annoying for debugging.

---

If you're not especially familiar with Rust, what's your particular context for/interest in this bug?

No special reason. I'm just a PL/compiler enthusiast. I improve my technical skills by solving some real problems. I didn't have the opportunity to get a comprehensive CS and PL education. So sometimes I may have weird conclusions and terminology (;△;).

[DianQK]

I re-looked at this IR and the associated code implementation.
I have some discoveries.

From the perspective of code implementation, I think this IR maybe is OK.
The IR doesn't have member function definitions directly associated with DICompositeTypes. The elements of !21 DICompositeType are empty.
Then I found a C++ example at D58538. !26 unit is !10, and !1 indirectly references !26. It's a similar case. D58786 is probably similar (I didn't look much at it).
I think these patches are a workaround with inconsistent scope and unit.

I started debugging why adding a declaration would solve this issue.

See DwarfUnit.cpp#L1163-L1166:

if (auto *SPDecl = SP->getDeclaration()) {
  if (!Minimal) {
    // Add subprogram definitions to the CU die directly.
    ContextDIE = &getUnitDie(); // Here. If there is a declaration, the parent DIE is set to the Unit DIE.

So for this IR, it just needs to add a declaration (we don't need add elements for !21)：

-!23 = distinct !DISubprogram(name: "alloc_impl", linkageName: "_ZN5alloc5alloc6Global10alloc_impl17h238d0844851c71a5E", scope: !21, file: !24, line: 170, type: !25, scopeLine: 170, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !1, templateParams: !3, retainedNodes: !3)
+!23 = distinct !DISubprogram(name: "alloc_impl", linkageName: "_ZN5alloc5alloc6Global10alloc_impl17h238d0844851c71a5E", scope: !21, file: !24, line: 170, type: !25, scopeLine: 170, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !1, declaration: !40, templateParams: !3, retainedNodes: !3)
...
+!40 = !DISubprogram(name: "alloc_impl", linkageName: "_ZN5alloc5alloc6Global10alloc_impl17h238d0844851c71a5E", scope: !21, file: !24, line: 170, type: !25, scopeLine: 170, flags: DIFlagPrototyped, spFlags: 0)

This has nothing to do with members, just a declaration to switch the parent DIE from scope to unit. I don't think this makes sense.
So I think this should address in LLVM.

But why is it inconsistent? I think this may be a bug in LTO. I'll continue to debug the DWARF code and take a look at the LTO later.
If I understand correctly, this is because the ODR merges the DICompositeType. In this case, it is possible that scope and unit refer to different CUs.

[DianQK]

I have a curiosity.
Can we change DIE *ContextDIE = Minimal ? &getUnitDie() : getOrCreateContextDIE(SP->getScope()); to DIE *ContextDIE = &getUnitDie();.
I understand that this code tends to select scope. Then switch to unit if it has a declaration.

[DianQK]

Improved CU selection, preferring unit when inconsistent.

[DianQK]

But why is it inconsistent?

If I understand correctly, this is because the ODR merges the DICompositeType. In this case, it is possible that scope and unit refer to different CUs.

[dblaikie]

This has nothing to do with members, just a declaration to switch the parent DIE from scope to unit. I don't think this makes sense.

Could you explain in more detail why you don't think this makes sense?

If I understand correctly, this is because the ODR merges the DICompositeType. In this case, it is possible that scope and unit refer to different CUs.

Roughly, yes. DICompositeTypes shouldn't have a scope that refers to a unit - they should be unit-agnostic. But DISubprograms do exist concretely in specific units (though, still, I don't think their scope field indicates that/should lead to any unit - it should just be a series of namespaces that leads to null) - so, since one DICompositeType can have two DISubprograms defined in different units - those DISubprograms can't be directly scoped inside the DICompositeType - they need to be indirected through declarations.

That's the fix at the source here - producers should produce declarations for these member functions and then it'll work.

I don't think we should workaround this issue in LLVM - producers should be fixed instead. At some point/if anything, LLVM's DebugInfo verifier should reject DWARF that looks like this (with defining DISubprograms scoped directly underneath DICompositeTypes).

[DianQK]

In D147620#4311265, @dblaikie wrote:

This has nothing to do with members, just a declaration to switch the parent DIE from scope to unit. I don't think this makes sense.

Could you explain in more detail why you don't think this makes sense?

This is my consideration only from the perspective of code implementation.
See DwarfUnit.cpp#L1157-L1166:

DIE *ContextDIE =
    Minimal ? &getUnitDie() : getOrCreateContextDIE(SP->getScope());

if (DIE *SPDie = getDIE(SP))
  return SPDie;

if (auto *SPDecl = SP->getDeclaration()) {
  if (!Minimal) {
    // Add subprogram definitions to the CU die directly.
    ContextDIE = &getUnitDie();

As above code, the ParentDIE of distinct !DISubprogram(name: "foo", scope: !21, spFlags: DISPFlagDefinition, unit: !1) is scope.
However, the ParentDIE of distinct !DISubprogram(name: "foo", scope: !21, spFlags: DISPFlagDefinition, unit: !1, declaration: !40) is unit. Just a declaration makes such a difference. So I don't think this makes sense.

Note that this has nothing to do with the members of DICompositeType.

I blame this code to Debug Info: use createAndAddDIE for newly-created Subprogram DIEs. Interestingly, I found this code to solve the DIE across CU/LTO problem.
From this patch, I am more convinced that my patch is a more suitable solution.
The declaration should not control the ContextDIE here.

---

That's the fix at the source here - producers should produce declarations for these member functions and then it'll work.

Based on the above explanation of declarations deciding DIE, I think the declaration and members should play some role in other debugging structures.

[cuviper]

In D147620#4311265, @dblaikie wrote:

That's the fix at the source here - producers should produce declarations for these member functions and then it'll work.

I have implemented this in rustc here: https://github.com/rust-lang/rust/pull/111167

It seems to be working -- we'll just have to make sure it doesn't break any consumers. Given that this is closer to what both Clang and GCC do for C++ methods, I'm hopeful.

[dblaikie]

In D147620#4320395, @cuviper wrote:

In D147620#4311265, @dblaikie wrote:

That's the fix at the source here - producers should produce declarations for these member functions and then it'll work.

I have implemented this in rustc here: https://github.com/rust-lang/rust/pull/111167

It seems to be working -- we'll just have to make sure it doesn't break any consumers. Given that this is closer to what both Clang and GCC do for C++ methods, I'm hopeful.

*fingers crossed* thanks for that!

[DianQK]

We prefer to resolve the issue by adding a declaration.

llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.h

public:
 
   void attachLowHighPC(DIE &D, const MCSymbol *Begin, const MCSymbol *End);
 
   /// Find DIE for the given subprogram and attach appropriate
   /// DW_AT_low_pc and DW_AT_high_pc attributes. If there are global
   /// variables in this scope then create and insert DIEs for these
   /// variables.
   DIE &updateSubprogramScopeDIE(const DISubprogram *SP);
-  DIE &updateSubprogramScopeDIEImpl(const DISubprogram *SP, DIE *SPDie);
 
   void constructScopeDIE(LexicalScope *Scope, DIE &ParentScopeDIE);
 
   /// A helper function to construct a RangeSpanList for a given
   /// lexical scope.
   void addScopeRangeList(DIE &ScopeDIE, SmallVector<RangeSpan, 2> Range);
 
   void attachRangesOrLowHighPC(DIE &D, SmallVector<RangeSpan, 2> Ranges);

llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp

void DwarfCompileUnit::attachLowHighPC(DIE &D, const MCSymbol *Begin,
 
   addLabelAddress(D, dwarf::DW_AT_low_pc, Begin);
   if (DD->getDwarfVersion() < 4)
     addLabelAddress(D, dwarf::DW_AT_high_pc, End);
   else
     addLabelDelta(D, dwarf::DW_AT_high_pc, End, Begin);
 }
 
-// Find DIE for the given subprogram and attach appropriate DW_AT_low_pc
-// and DW_AT_high_pc attributes. If there are global variables in this
-// scope then create and insert DIEs for these variables.
-DIE &DwarfCompileUnit::updateSubprogramScopeDIE(const DISubprogram *SP) {
-  DIE *SPDie = getOrCreateSubprogramDIE(SP, includeMinimalInlineScopes());
-  auto *ContextCU = static_cast<DwarfCompileUnit *>(SPDie->getUnit());
-  return ContextCU->updateSubprogramScopeDIEImpl(SP, SPDie);
-}
-
 // Add info for Wasm-global-based relocation.
 // 'GlobalIndex' is used for split dwarf, which currently relies on a few
 // assumptions that are not guaranteed in a formal way but work in practice.
 void DwarfCompileUnit::addWasmRelocBaseGlobal(DIELoc *Loc, StringRef GlobalName,
                                               uint64_t GlobalIndex) {
   // FIXME: duplicated from Target/WebAssembly/WebAssembly.h
   // don't want to depend on target specific headers in this code?
   const unsigned TI_GLOBAL_RELOC = 3;
if (!isDwoUnit()) {
     // symbols are (with entries in .debug_addr).
     // For now we hardcode the indices in the callsites. Global indices are not
     // fixed, but in practice a few are fixed; for example, __stack_pointer is
     // always index 0.
     addUInt(*Loc, dwarf::DW_FORM_data4, GlobalIndex);
   }
 }
 
-DIE &DwarfCompileUnit::updateSubprogramScopeDIEImpl(const DISubprogram *SP,
-                                                    DIE *SPDie) {
+// Find DIE for the given subprogram and attach appropriate DW_AT_low_pc
+// and DW_AT_high_pc attributes. If there are global variables in this
+// scope then create and insert DIEs for these variables.
+DIE &DwarfCompileUnit::updateSubprogramScopeDIE(const DISubprogram *SP) {
+  DIE *SPDie = getOrCreateSubprogramDIE(SP, includeMinimalInlineScopes());
   SmallVector<RangeSpan, 2> BB_List;
   // If basic block sections are on, ranges for each basic block section has
   // to be emitted separately.
   for (const auto &R : Asm->MBBSectionRanges)
     BB_List.push_back({R.second.BeginLabel, R.second.EndLabel});
 
   attachRangesOrLowHighPC(*SPDie, BB_List);
 
while (!WorkList.empty()) {
     }
   }
   return Result;
 }
 
 DIE &DwarfCompileUnit::constructSubprogramScopeDIE(const DISubprogram *Sub,
                                                    LexicalScope *Scope) {
   DIE &ScopeDIE = updateSubprogramScopeDIE(Sub);
-  auto *ContextCU = static_cast<DwarfCompileUnit *>(ScopeDIE.getUnit());
 
   if (Scope) {
     assert(!Scope->getInlinedAt());
     assert(!Scope->isAbstractScope());
     // Collect lexical scope children first.
     // ObjectPointer might be a local (non-argument) local variable if it's a
     // block's synthetic this pointer.
-    if (DIE *ObjectPointer =
-            ContextCU->createAndAddScopeChildren(Scope, ScopeDIE))
-      ContextCU->addDIEEntry(ScopeDIE, dwarf::DW_AT_object_pointer,
-                             *ObjectPointer);
+    if (DIE *ObjectPointer = createAndAddScopeChildren(Scope, ScopeDIE))
+      addDIEEntry(ScopeDIE, dwarf::DW_AT_object_pointer, *ObjectPointer);
   }
 
   // If this is a variadic function, add an unspecified parameter.
   DITypeRefArray FnArgs = Sub->getType()->getTypeArray();
 
   // If we have a single element of null, it is a function that returns void.
   // If we have more than one elements and the last one is null, it is a
   // variadic function.

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h

void constructCallSiteEntryDIEs(const DISubprogram &SP, DwarfCompileUnit &CU,
                                   DIE &ScopeDIE, const MachineFunction &MF);
 
   template <typename DataT>
   void addAccelNameImpl(const DICompileUnit &CU, AccelTable<DataT> &AppleAccel,
                         StringRef Name, const DIE &Die);
 
   void finishEntityDefinitions();
 
+  DwarfCompileUnit &getSubprogramDIEScopeCU(const DISubprogram *SP);
+
   void finishSubprogramDefinitions();
 
   /// Finish off debug information after all functions have been
   /// processed.
   void finalizeModuleInfo();
 
   /// Emit the debug info section.
   void emitDebugInfo();

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

for (const auto &Entity : ConcreteEntities) {
     // in the ConcreteEntities list, rather than looking it up again here.
     // DIE::getUnit isn't simple - it walks parent pointers, etc.
     DwarfCompileUnit *Unit = CUDieMap.lookup(Die->getUnitDie());
     assert(Unit);
     Unit->finishEntityDefinition(Entity.get());
   }
 }
 
+DwarfCompileUnit &DwarfDebug::getSubprogramDIEScopeCU(const DISubprogram *SP) {
+  DwarfCompileUnit *ContextCU = CUMap.lookup(SP->getUnit());
+  DIE *ContextDIE = ContextCU->getOrCreateContextDIE(SP->getScope());
+  ContextCU = static_cast<DwarfCompileUnit *>(ContextDIE->getUnit());
+  return *ContextCU;
+}
+
 void DwarfDebug::finishSubprogramDefinitions() {
   for (const DISubprogram *SP : ProcessedSPNodes) {
     assert(SP->getUnit()->getEmissionKind() != DICompileUnit::NoDebug);
-    forBothCUs(
-        getOrCreateDwarfCompileUnit(SP->getUnit()),
-        [&](DwarfCompileUnit &CU) { CU.finishSubprogramDefinition(SP); });
+    DwarfCompileUnit &TheCU = getSubprogramDIEScopeCU(SP);
+
+    forBothCUs(TheCU, [&](DwarfCompileUnit &CU) {
+      CU.finishSubprogramDefinition(SP);
+    });
   }
 }
 
 void DwarfDebug::finalizeModuleInfo() {
   const TargetLoweringObjectFile &TLOF = Asm->getObjFileLowering();
 
   finishSubprogramDefinitions();
 
void DwarfDebug::endFunctionImpl(const MachineFunction *MF) {
   assert(CurFn == MF &&
       "endFunction should be called with the same function as beginFunction");
 
   // Set DwarfDwarfCompileUnitID in MCContext to default value.
   Asm->OutStreamer->getContext().setDwarfCompileUnitID(0);
 
   LexicalScope *FnScope = LScopes.getCurrentFunctionScope();
   assert(!FnScope || SP == FnScope->getScopeNode());
-  DwarfCompileUnit &TheCU = *CUMap.lookup(SP->getUnit());
+
+  DwarfCompileUnit &TheCU = getSubprogramDIEScopeCU(SP);
+
   if (TheCU.getCUNode()->isDebugDirectivesOnly()) {
     PrevLabel = nullptr;
     CurFn = nullptr;
     return;
   }
 
   DenseSet<InlinedEntity> Processed;
   collectEntityInfo(TheCU, SP, Processed);

llvm/test/DebugInfo/Generic/cross-cu-inlining-2.ll

 !34 = distinct !DISubprogram(name: "bar", scope: !31, file: !4, line: 21, type: !27, scopeLine: 21, unit: !3, retainedNodes: !2)
 !35 = !DILocation(line: 0, scope: !36, inlinedAt: !37)
 !36 = distinct !DISubprogram(name: "goo", scope: !26, file: !30, type: !27, unit: !3, retainedNodes: !2)
 !37 = !DILocation(line: 21, column: 26, scope: !34)
 
 ; CHECK: DW_TAG_compile_unit
 ; CHECK:   DW_TAG_module
 ; CHECK:     DW_TAG_structure_type
-; CHECK: [[INIT:0x.*]]: DW_TAG_subprogram
-; CHECK;         DW_AT_name [DW_FORM_strp]  ({{.*}} = "init")
 ; CHECK:       DW_TAG_subprogram
-; CHECK;         DW_AT_name [DW_FORM_strp]  ({{.*}} = "bar")
+; CHECK;         DW_AT_name [DW_FORM_strp]  ({{.*}} = "foo")
 ; CHECK:         DW_TAG_inlined_subroutine
-; CHECK:           DW_AT_abstract_origin [DW_FORM_ref_addr] (0x00000000[[GOO:.*]] "goo")
+; CHECK:           DW_AT_abstract_origin [DW_FORM_ref4]  ({{.*}} => {[[INIT:0x.*]]} "init")
 ; CHECK:         NULL
 ; CHECK:       NULL
 ; CHECK:     DW_TAG_structure_type
+; CHECK:[[INIT]]: DW_TAG_subprogram
+; CHECK;         DW_AT_name [DW_FORM_strp]  ({{.*}} = "init")
 ; CHECK:       DW_TAG_subprogram
-; CHECK;         DW_AT_name [DW_FORM_strp]  ({{.*}} = "foo")
+; CHECK;         DW_AT_name [DW_FORM_strp]  ({{.*}} = "bar")
 ; CHECK:         DW_TAG_inlined_subroutine
-; CHECK:           DW_AT_abstract_origin [DW_FORM_ref4]  ({{.*}} => {[[INIT]]} "init")
+; CHECK:           DW_AT_abstract_origin [DW_FORM_ref_addr] (0x00000000[[GOO:.*]] "goo")
 ; CHECK:         NULL
 ; CHECK:       NULL
 ; CHECK:     NULL
 ; CHECK:   NULL
 ; CHECK: DW_TAG_compile_unit
 ; CHECK:   DW_TAG_module
 ; CHECK: 0x[[GOO]]: DW_TAG_subprogram
 ; CHECK;       DW_AT_name [DW_FORM_strp]  ({{.*}} = "goo")
 ; CHECK:     NULL
 ; CHECK:   NULL

llvm/test/DebugInfo/Generic/cross-cu.ll

+; RUN: %llc_dwarf %s -O1 -mtriple=x86_64-unknown-unknown -filetype=obj -o %t.o
+; RUN: %llc_dwarf %s -O0 -filetype=obj -o %t.o
+; RUN: llvm-dwarfdump %t.o --debug-info --verbose | FileCheck %s
+; RUN: llvm-dwarfdump %t.o --debug-info --verify
+
+declare void @llvm.dbg.declare(metadata, metadata, metadata)
+
+define { ptr, i64 } @test(i1 %0, ptr %1) !dbg !23 {
+  %3 = alloca i64, i32 0, align 8
+  call void @llvm.dbg.declare(metadata ptr %3, metadata !26, metadata !DIExpression()), !dbg !29
+  %4 = icmp eq i64 0, 0
+  br i1 %4, label %5, label %6
+
+5:                                                ; preds = %2
+  store ptr null, ptr null, align 8, !dbg !30
+  store i64 0, ptr %1, align 8
+  ret { ptr, i64 } zeroinitializer
+
+6:                                                ; preds = %2
+  br i1 %0, label %9, label %7, !dbg !31
+
+7:                                                ; preds = %6
+  %8 = load i64, ptr null, align 8, !dbg !32
+  store i64 %8, ptr %1, align 8
+  ret { ptr, i64 } zeroinitializer
+
+9:                                                ; preds = %6
+  store i64 0, ptr null, align 8
+  ret { ptr, i64 } zeroinitializer
+}
+
+define void @test2() cold !dbg !33 {
+  unreachable
+}
+
+!llvm.module.flags = !{!0}
+!llvm.dbg.cu = !{!1, !4}
+
+!0 = !{i32 2, !"Debug Info Version", i32 3}
+!1 = distinct !DICompileUnit(language: DW_LANG_Rust, file: !2, producer: "clang LLVM (rustc version 1.70.0-nightly (ec2f40c6b 2023-03-30))", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !3, splitDebugInlining: false)
+!2 = !DIFile(filename: "src/lib.rs/@/3jkrl8oz9knrf4o4", directory: "/home/npopov/repos/test")
+!3 = !{}
+!4 = distinct !DICompileUnit(language: DW_LANG_Rust, file: !5, producer: "clang LLVM (rustc version 1.70.0-nightly (ec2f40c6b 2023-03-30))", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !3, globals: !6, splitDebugInlining: false)
+!5 = !DIFile(filename: "src/lib.rs/@/4r9uiw0o66d13q4b", directory: "/home/npopov/repos/test")
+!6 = !{!7}
+!7 = !DIGlobalVariableExpression(var: !8, expr: !DIExpression())
+!8 = distinct !DIGlobalVariable(name: "<&alloc::vec::Vec<u32, alloc::alloc::Global> as core::fmt::Debug>::{vtable}", scope: null, file: !9, type: !10, isLocal: true, isDefinition: true)
+!9 = !DIFile(filename: "<unknown>", directory: "")
+!10 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "<&alloc::vec::Vec<u32, alloc::alloc::Global> as core::fmt::Debug>::{vtable_type}", file: !9, size: 256, align: 64, flags: DIFlagArtificial, elements: !3, vtableHolder: !11, templateParams: !3, identifier: "8b5b18a5b595fd2726a060be925b88b2")
+!11 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "&alloc::vec::Vec<u32, alloc::alloc::Global>", baseType: !12, size: 64, align: 64, dwarfAddressSpace: 0)
+!12 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Vec<u32, alloc::alloc::Global>", scope: !13, file: !9, size: 192, align: 64, elements: !15, templateParams: !3, identifier: "528a0d32ae6e19b7d83105274ce701fc")
+!13 = !DINamespace(name: "vec", scope: !14)
+!14 = !DINamespace(name: "alloc", scope: null)
+!15 = !{!16}
+!16 = !DIDerivedType(tag: DW_TAG_member, name: "buf", scope: !12, file: !9, baseType: !17, size: 128, align: 64)
+!17 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "RawVec<u32, alloc::alloc::Global>", scope: !18, file: !9, size: 128, align: 64, elements: !3, templateParams: !19, identifier: "67d483d3bf48782733e92e6e5b9d5f14")
+!18 = !DINamespace(name: "raw_vec", scope: !14)
+!19 = !{!20}
+!20 = !DITemplateTypeParameter(name: "A", type: !21)
+!21 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Global", scope: !22, file: !9, align: 8, elements: !3, identifier: "8b09da5419eb6d204173b283709c5949")
+!22 = !DINamespace(name: "alloc", scope: !14)
+!23 = distinct !DISubprogram(name: "alloc_impl", linkageName: "_ZN5alloc5alloc6Global10alloc_impl17h238d0844851c71a5E", scope: !21, file: !24, line: 170, type: !25, scopeLine: 170, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !1, templateParams: !3, retainedNodes: !3)
+!24 = !DIFile(filename: "/rustc/ec2f40c6b04f0e9850dd1f454e8639d319f4ed9b/library/alloc/src/alloc.rs", directory: "", checksumkind: CSK_MD5, checksum: "4972b0b4c31877237f60deae5d06e8ce")
+!25 = distinct !DISubroutineType(types: !3)
+!26 = !DILocalVariable(name: "size", scope: !27, file: !24, line: 174, type: !28, align: 8)
+!27 = distinct !DILexicalBlock(scope: !23, file: !24, line: 174, column: 13)
+!28 = !DIBasicType(name: "usize", size: 64, encoding: DW_ATE_unsigned)
+!29 = !DILocation(line: 174, column: 13, scope: !27)
+!30 = !DILocation(line: 172, column: 51, scope: !23)
+!31 = !DILocation(line: 175, column: 34, scope: !27)
+!32 = !DILocation(line: 175, column: 79, scope: !27)
+!33 = distinct !DISubprogram(name: "assert_failed<alloc::vec::Vec<u32, alloc::alloc::Global>, alloc::vec::Vec<u32, alloc::alloc::Global>>", linkageName: "_ZN4core9panicking13assert_failed17h49f83a394aded8c4E", scope: !35, file: !34, line: 204, type: !37, scopeLine: 204, flags: DIFlagPrototyped | DIFlagNoReturn, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !4, templateParams: !3, retainedNodes: !3)
+!34 = !DIFile(filename: "/rustc/ec2f40c6b04f0e9850dd1f454e8639d319f4ed9b/library/core/src/panicking.rs", directory: "", checksumkind: CSK_MD5, checksum: "83265ee8d3fb756102ca03de7bd05933")
+!35 = !DINamespace(name: "panicking", scope: !36)
+!36 = !DINamespace(name: "core", scope: null)
+!37 = distinct !DISubroutineType(types: !38)
+!38 = !{null}
+
+; CHECK: DW_TAG_compile_unit
+; CHECK:   DW_AT_name [DW_FORM_strp]  ({{.*}} = "src/lib.rs/@/4r9uiw0o66d13q4b")
+; CHECK:   DW_AT_low_pc [DW_FORM_addr]
+; CHECK:   DW_AT_high_pc [DW_FORM_data4]
+; CHECK: DW_TAG_compile_unit
+; CHECK:   DW_AT_name [DW_FORM_strp]  ({{.*}} = "src/lib.rs/@/3jkrl8oz9knrf4o4")
+; CHECK-NOT:   DW_AT_low_pc [DW_FORM_addr]
+; CHECK-NOT:   DW_AT_high_pc [DW_FORM_data4]