[DWARF] Create subprogram's DIE in the unit specified by its DISubprogram

[jmorse]

Summary

This is a fix for PR48790 [0]. 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 [0], 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 [0], gets run through llvm-dwarfdump -verify and has its output examined to ensure "eee" is in the CU for 2.cpp.

[0] https://bugs.llvm.org/show_bug.cgi?id=48790

[dblaikie]

(seems there is perhaps some nearby pretty problematic issues I'm just writing down here because I saw it: Generally there are two kinds of DISubprograms: definition DISubprograms are "distinct" and referenced/kept alive from an llvm::Function's subprogram attachment. Declaration DISubprograms are not distinct and referenced from the member list of a DICompositeType, for instance. That's the simple case - if IR Linking occurs, one copy of an llvm::Function definition is retained, along with its referenced DISubprogram, simple enough. But it seems we are keeping definition DISubprograms alive through a few other means (or declaration DISubprograms, perhaps) - such as from call site metadata, using declarations, and the scope chains for types like lambdas. These DISubprograms aren't properly deduplicated because they can't necessarily piggyback on the llvm::Function deduplication: They are referenced from multiple parts of the debug info metadata - this can lead to buggy/weird DWARF like this:

$ cat a.cpp 
namespace ns {
inline void f1() {
}
}
void f3() {
  ns::f1();
}
$ cat b.cpp
namespace ns {
inline void f1() {
}
}
void f2() { ns::f1(); }
using ns::f1;
void f3();
int main() {
  f3();
  f2();
}
$ ~/dev/llvm/build/default/bin/clang++ -fuse-ld=lld -g -flto a.cpp b.cpp && llvm-dwarfdump-tot a.out
a.out:  file format elf64-x86-64

.debug_info contents:
0x00000000: Compile Unit: length = 0x0000006e, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000072)

0x0000000b: DW_TAG_compile_unit
              DW_AT_producer    ("clang version 12.0.0 ([e-mail]:llvm/llvm-project.git 05f846b97e222815b36efa815cbc67802c3e283c)")
              DW_AT_language    (DW_LANG_C_plus_plus_14)
              DW_AT_name        ("b.cpp")
              DW_AT_stmt_list   (0x00000000)
              DW_AT_comp_dir    ("/usr/local/google/home/blaikie/dev/scratch")
              DW_AT_low_pc      (0x0000000000000000)
              DW_AT_ranges      (0x00000000
                 [0x00000000002017c0, 0x00000000002017cb)
                 [0x00000000002017d0, 0x00000000002017e2))

0x0000002a:   DW_TAG_namespace
                DW_AT_name      ("ns")

0x0000002f:     DW_TAG_subprogram

0x00000030:     NULL

0x00000031:   DW_TAG_imported_declaration
                DW_AT_decl_file ("/usr/local/google/home/blaikie/dev/scratch/b.cpp")
                DW_AT_decl_line (6)
                DW_AT_import    (0x0000002f)

0x00000038:   DW_TAG_subprogram
                DW_AT_low_pc    (0x00000000002017c0)
                DW_AT_high_pc   (0x00000000002017cb)
                DW_AT_frame_base        (DW_OP_reg6 RBP)
                DW_AT_linkage_name      ("_Z2f2v")
                DW_AT_name      ("f2")
                DW_AT_decl_file ("/usr/local/google/home/blaikie/dev/scratch/b.cpp")
                DW_AT_decl_line (5)
                DW_AT_external  (true)

0x00000051:   DW_TAG_subprogram
                DW_AT_low_pc    (0x00000000002017d0)
                DW_AT_high_pc   (0x00000000002017e2)
                DW_AT_frame_base        (DW_OP_reg6 RBP)
                DW_AT_name      ("main")
                DW_AT_decl_file ("/usr/local/google/home/blaikie/dev/scratch/b.cpp")
                DW_AT_decl_line (8)
                DW_AT_type      (0x0000006a "int")
                DW_AT_external  (true)

0x0000006a:   DW_TAG_base_type
                DW_AT_name      ("int")
                DW_AT_encoding  (DW_ATE_signed)
                DW_AT_byte_size (0x04)

0x00000071:   NULL
0x00000072: Compile Unit: length = 0x0000005f, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x000000d5)

0x0000007d: DW_TAG_compile_unit
              DW_AT_producer    ("clang version 12.0.0 ([e-mail]:llvm/llvm-project.git 05f846b97e222815b36efa815cbc67802c3e283c)")
              DW_AT_language    (DW_LANG_C_plus_plus_14)
              DW_AT_name        ("a.cpp")
              DW_AT_stmt_list   (0x00000059)
              DW_AT_comp_dir    ("/usr/local/google/home/blaikie/dev/scratch")
              DW_AT_low_pc      (0x0000000000000000)
              DW_AT_ranges      (0x00000030
                 [0x00000000002017a0, 0x00000000002017ab)
                 [0x00000000002017b0, 0x00000000002017b6))

0x0000009c:   DW_TAG_subprogram
                DW_AT_low_pc    (0x00000000002017a0)
                DW_AT_high_pc   (0x00000000002017ab)
                DW_AT_frame_base        (DW_OP_reg6 RBP)
                DW_AT_linkage_name      ("_Z2f3v")
                DW_AT_name      ("f3")
                DW_AT_decl_file ("/usr/local/google/home/blaikie/dev/scratch/a.cpp")
                DW_AT_decl_line (5)
                DW_AT_external  (true)

0x000000b5:   DW_TAG_namespace
                DW_AT_name      ("ns")

0x000000ba:     DW_TAG_subprogram
                  DW_AT_low_pc  (0x00000000002017b0)
                  DW_AT_high_pc (0x00000000002017b6)
                  DW_AT_frame_base      (DW_OP_reg6 RBP)
                  DW_AT_linkage_name    ("_ZN2ns2f1Ev")
                  DW_AT_name    ("f1")
                  DW_AT_decl_file       ("/usr/local/google/home/blaikie/dev/scratch/a.cpp")
                  DW_AT_decl_line       (2)
                  DW_AT_external        (true)

0x000000d3:     NULL

0x000000d4:   NULL
$ cat ab.ll | grep f1
$_ZN2ns2f1Ev = comdat any
  call void @_ZN2ns2f1Ev(), !dbg !18
define linkonce_odr dso_local void @_ZN2ns2f1Ev() #1 comdat !dbg !20 {
  call void @_ZN2ns2f1Ev(), !dbg !23
!7 = distinct !DISubprogram(name: "f1", linkageName: "_ZN2ns2f1Ev", scope: !8, file: !4, line: 2, type: !9, scopeLine: 2, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !3, retainedNodes: !2)
!20 = distinct !DISubprogram(name: "f1", linkageName: "_ZN2ns2f1Ev", scope: !8, file: !1, line: 2, type: !9, scopeLine: 2, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)

Which is a bit problematic. Almost feels like the solution to that is to have the debug info metadata refer (weakly) to the llvm::Function instead of the distinct DISubprogram... 

I would expect this should show up for call site debug info too, which might catch more interest from the folks who've been implementing that more recently. Oh, maybe it doesn't show up there - precisely because that debug info does essentially refer to the llvm::Function (more specifically call site debug info isn't carried in the IR at all (except by adding DISubprograms to llvm::Function declarations, which isn't otherwise used/needed) - it's created at the backend).

Might be able to tickle something like this with the scoping issue you've got here - even with this bug fixed, if you had the sort of cross-CU referencing I've created in this example)

llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp

1083–1092

This seems a bit more complicated than it needs to be (does it need to check skeleton DIEs, etc?)

The code I'd expect would be something like DwarfDebug's constructSubprogramDefinitionDIE - perhaps updating the caller to call constructSubprogramDefinitionDIE rather than modifying getOrCreateSubprogramDIE would be suitable.

(I realize this leaves open the possibility that other callers might need the same treatment - an assertion here that DD->getOrCreateDwarfCompileUnit(SP) == this might be good to catch those & see if there's a more systemic issue to be addressed?)

llvm/test/DebugInfo/X86/subprogram-across-cus.ll

7–29

Would be good to simplify this down a bit as I did in the bug - it doesn't need a lambda (a named local type will do - without a need for any members, etc) or a while loop, or the extra 'xxx' type, 'ccc' can be a static member to avoid the need to describe a parameter.

[jmorse]

Replace regression test with David's smaller test

[jmorse]

Change interception of Subprogram creation to call back out to DwarfDebug instead of looking up CUs within DwarfUnit.

[jmorse]

Responding to inline comment that's now sort-of-orphaned: calling back out to constructSubprogramDefinitionDIE sounds good, I've added that to DwarfUnit::getOrCreateContextDIE with a comment.

IMHO, getOrCreateContextDIE is a large part of the problem here, callers use it to create DIEs without actually caring what kind of DIE it is, and so they're not able to make decisions about what CU the DIE should be created in. In the call stack [0] where the fault occurs, it's the earliest point that we can identify we're going to create a Subprogram, and so might need to change unit.

(The skeleton faff was because the DebugInfo/X86/fission-inline.ll test failed otherwise, looks like constructSubprogramDefinitionDIE takes care of that now).

[0] https://gist.github.com/jmorse/bb283cd69b351a8ad568f26a50c5553c

llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp

863

Changed this to call getOrCreateContextDIE so that it'll switch on whether the SP is a definition or a declaration.

[dblaikie]

llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp

863

Hmm, this doesn't make sense to me - my expectation would be that definitions never appear in the elements list of a class/structure type DI metadata. (I'd expect a definition DISubprogram to be attached to an llvm::Function, and for that DISubprogram to refer to a declaration DISubprogram in the structure type's elements/member list)

Do you have an example where there are definitions in the elements list?

(at least, even if this is valid - it doesn't seem to be covered by the test?)

llvm/test/DebugInfo/X86/subprogram-across-cus.ll

32

Probably good to include the compile commands here (though handy to have the bug reference for extra context).

[jmorse]

Remove needless redirect of subprogram creation; add original compile commands to test case.

[jmorse]

llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp

863

No example, I added this to be conservative, I was confident all the other call sites would be safe against definition/declaration differences except this. Now removed!

[dblaikie]

llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp

525–530

Are these ever declarations/non-definitions? (I can't think of a place where we'd create a declaration as a scope) Perhaps this could just assert that the SP is a definition?

[jmorse]

llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp

525–530

Not to my knowledge -- again, this isn't my comfort zone. I stuck an assertion in and ran a stage2 RelWithDebInfo build and it didn't fire, that'd good assurance IMO.

[jmorse]

We don't create declaration DISubprograms as scopes, so don't handle it in getOrCreateContextDIE.

[dblaikie]

Looks good - thanks!

[jmorse]

Re-opening this as D95622 reverted it, because using type units led to various crashes and assertions. My revision to this patch just disables the new behaviour (created subprograms in their preferred unit) when using type units.

Here's a reduced reproducer that crashes for me with clang -O3 -g -mllvm -generate-type-units -c.

enum a {};
inline a b() {
  auto c = [] {};
}
void d(int) { b; }

I believe the type for lambda "c" is placed in a type unit. The type unit creates the scope of the lambda (subprogram "b") , the DIE for which is placed in the normal compile unit with this patch applied. However, the type information added to the subprogram to complete the type unit comes from that type units bump allocator pool. The result is that when the type unit is disposed of, the subprogram in the normal compile unit has children in freed memory. This annoys asan, which reports a use-after-free.

Using the old behaviour for type units seems to work just fine, DwarfUnit::isShareableAcrossCUs already disallows subprogram sharing when type units are used, which my change to. I continue to worry that there's more hidden beneath the surface here :(

[dblaikie]

Looks no worse than before at least.

Seems GCC doesn't include any scope information in the type units for function-local types. (though for namespace-scoped types GCC does include the namespaces in the type unit - but if the type is local to a namespace scoped function, none of the scoping is included in the type unit... ) - so might be worth changing our behavior to match tehre too (because the current behavior of a subprogram with no name, etc, isn't really useful - doesn't seem to get in gdb's way, but doesn't add any value either )

[MaskRay]

Heads-up: this patch seems to cause malformed .debug_gnu_pubnames with -fsanitize=cfi -gsplit-dwarf with some internal targets. I will report back when I have done more investigation.

% llvm-dwarfdump -debug-gnu-pubnames spinlock.pic.o > /dev/null
error: name lookup table at offset 0x13d9 has a terminator at offset 0x13e7 before the expected end at 0x140a

[dblaikie]

In D94976#2543257, @MaskRay wrote:

Heads-up: this patch seems to cause malformed .debug_gnu_pubnames with -fsanitize=cfi -gsplit-dwarf with some internal targets. I will report back when I have done more investigation.

% llvm-dwarfdump -debug-gnu-pubnames spinlock.pic.o > /dev/null
error: name lookup table at offset 0x13d9 has a terminator at offset 0x13e7 before the expected end at 0x140a

Might've been more suitable to rollback the original patch rather than implementing an untested hack without a clear explanation for why the problem arises in the first place. (perhaps this papers over more fundamental issues, etc)

@jmorse - would you mind reverting both this patch and @MaskRay's workaround while a test case is being worked on? (sounds like @MaskRay is working on providing that, yeah?)

[teemperor]

This probably also caused two debuginfo-tests to regress when running against LLDB (at least that's the only relevant commit in the change log)

debuginfo-tests.dexter-tests.nrvo-string.cpp
debuginfo-tests.llgdb-tests.nrvo-string.cpp

See http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/28154/

[jmorse]

In D94976#2548292, @teemperor wrote:

This probably also caused two debuginfo-tests to regress when running against LLDB (at least that's the only relevant commit in the change log)

That sounds a lot like it -- I'll get onto reverting then.

Maskrays reproducer ended up here https://reviews.llvm.org/D95617#2547111 I think, quoting:

Reproduce: https://gist.github.com/MaskRay/4c67b29bb038d5a016260437c9e25a7a

# git revert -n 56fa34ae3570a34fd0f4c2cf1bfaf095da01a959 # revert the workaround
% cat run.sh 
#!/bin/sh -e
llc -split-dwarf-file x.dwo -filetype=obj $1 -o x.o
if llvm-dwarfdump -debug-gnu-pubnames x.o 2> log; then
  exit 1
fi
grep 'name lookup table at' log
% ./run.sh a.ll
error: name lookup table at offset 0x12cc has a terminator at offset 0x12da before the expected end at 0x12fd

[teemperor]

Thank you! Let me know if you need help reproducing the debuginfo failures.

[jmorse]

The immediate cause of the failure in Maskrays reproducer is that a zero DIE offset is emitted to .debug_gnu_pubnames, which is interpreted as the (premature) end of the names list. Putting assert(Entity->getOffset() != 0); in [0] fails.

The reason why we get a zero offset is due to the following arrangements of debug-info:

• This function [1] has an inlined copy of "LowLevelCallOnce<(lambda at internal/sysinfo.cc:299:28)>"
• "LowLevelCallOnce" has a template type "Callable", with a type that's node !2140 in the input LLVM-IR,
• That type is in the scope of a subprogram, "NumCPUs", which is created in a separate CU,
• "NumCPUs" is in a namespace "base_internal", in another namespace "absl".

So far this is fine. With this patch applied we change the CU that "NumCPUs" is created in to another (from node !2 to !1446). However: this unit only has a skeleton DIE emitted. When the "absl" namespace is created, DwarfUnit adds it directly to the unit DIE (not the skeleton) and list of globals [2]. When emitting .debug_gnu_pubnames, we refer to a DIE that hasn't been (and won't be) emitted in the unit DIE, thus getting a zero offset.

Exactly which piece is at fault here is a bit opaque to me; I'll carry on studying what's going on.

[0] https://github.com/llvm/llvm-project/blob/79b222c39f0e4377b49191b6aba080b1607f3fa7/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp#L2394
[1] "_ZN4absl13base_internal12CallOnceImplIZNS0_8SpinLock8SpinLoopEvE3$_0JEEEvPNSt3__16atomicIjEENS0_14SchedulingModeEOT_DpOT0_"
[2] https://github.com/llvm/llvm-project/blob/79b222c39f0e4377b49191b6aba080b1607f3fa7/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp#L1066

[dblaikie]

Could be related to a change I made maybe a couple of years ago to avoid emitting split units when there was nothing of interest in the split unit. I forget where that code is exactly - but this was part of a set of fixes I made for a few related issues due to a ThinLTO debug info case - something was causing excess CU fragments under ThinLTO, ecah of which was being split even though there wasn't anything interesting in the split part.

Might be necessary to tweak the condition for that CU elision - I can go looking for more detail on exactly where/how that works, if you like.

[jmorse]

Might be necessary to tweak the condition for that CU elision - I can go looking for more detail on exactly where/how that works, if you like.

Yes please, it sounds like a likely cause of this. The global pubnames list seems like a side-channel that could affect that elision.

(Re-opening this as it's still not stuck a landing).

[teemperor]

I did some bisecting and I found out the debuginfo tests have incorrect build dependencies and this commit was *not* at fault (someone/something deleted the built test binaries and caused a long overdue rebuild). The commit that enabled the new pass manager actually caused the tests to fail.

[jmorse]

Abandoning in favour of D107076, which reverts the shared-subprogram behaviour, no cycles to hunt down the which-unit-owns-what issues I ran into. I added the regression test from here in that revert.

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h

DbgEntity *createConcreteEntity(DwarfCompileUnit &TheCU,
                                   LexicalScope &Scope,
                                   const DINode *Node,
                                   const DILocation *Location,
                                   const MCSymbol *Sym = nullptr);
 
   /// Construct a DIE for this abstract scope.
   void constructAbstractSubprogramScopeDIE(DwarfCompileUnit &SrcCU, LexicalScope *Scope);
 
-  /// Construct a DIE for the subprogram definition \p SP and return it.
-  DIE &constructSubprogramDefinitionDIE(const DISubprogram *SP);
-
   /// Construct DIEs for call site entries describing the calls in \p MF.
   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);
 
public:
   uint16_t getDwarfVersion() const;
 
   /// Returns a suitable DWARF form to represent a section offset, i.e.
   /// * DW_FORM_sec_offset for DWARF version >= 4;
   /// * DW_FORM_data8 for 64-bit DWARFv3;
   /// * DW_FORM_data4 for 32-bit DWARFv3 and DWARFv2.
   dwarf::Form getDwarfSectionOffsetForm() const;
 
+  /// Construct a DIE for the subprogram definition \p SP and return it.
+  DIE &constructSubprogramDefinitionDIE(const DISubprogram *SP);
+
   /// Returns the previous CU that was being updated
   const DwarfCompileUnit *getPrevCU() const { return PrevCU; }
   void setPrevCU(const DwarfCompileUnit *PrevCU) { this->PrevCU = PrevCU; }
 
   /// Returns the entries for the .debug_loc section.
   const DebugLocStream &getDebugLocs() const { return DebugLocs; }
 
   /// Emit an entry for the debug loc section. This can be used to

llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp

 
 DIE *DwarfUnit::getOrCreateContextDIE(const DIScope *Context) {
   if (!Context || isa<DIFile>(Context))
     return &getUnitDie();
   if (auto *T = dyn_cast<DIType>(Context))
     return getOrCreateTypeDIE(T);
   if (auto *NS = dyn_cast<DINamespace>(Context))
     return getOrCreateNameSpace(NS);
-  if (auto *SP = dyn_cast<DISubprogram>(Context))
+  if (auto *SP = dyn_cast<DISubprogram>(Context)) {
+    // Subprogram definitions should be created in the Unit that they specify,
+    // which might not be "this" unit when type definitions move around under
+    // LTO.
+    if (SP->isDefinition())
+      return &DD->constructSubprogramDefinitionDIE(SP);
     return getOrCreateSubprogramDIE(SP);
+  }
   if (auto *M = dyn_cast<DIModule>(Context))
     return getOrCreateModule(M);
   return getDIE(Context);
 }
 
 DIE *DwarfUnit::createTypeDIE(const DICompositeType *Ty) {
   auto *Context = Ty->getScope();
   DIE *ContextDIE = getOrCreateContextDIE(Context);
if (Tag == dwarf::DW_TAG_class_type ||
       addTemplateParams(Buffer, CTy->getTemplateParams());
 
     // Add elements to structure type.
     DINodeArray Elements = CTy->getElements();
     for (const auto *Element : Elements) {
       if (!Element)
         continue;
       if (auto *SP = dyn_cast<DISubprogram>(Element))
         getOrCreateSubprogramDIE(SP);
       else if (auto *DDTy = dyn_cast<DIDerivedType>(Element)) {
         if (DDTy->getTag() == dwarf::DW_TAG_friend) {
           DIE &ElemDie = createAndAddDIE(dwarf::DW_TAG_friend, Buffer);
           addType(ElemDie, DDTy->getBaseType(), dwarf::DW_AT_friend);
         } else if (DDTy->isStaticMember()) {
           getOrCreateStaticMemberDIE(DDTy);
         } else if (Tag == dwarf::DW_TAG_variant_part) {
           // When emitting a variant part, wrap each member in
if (M->getLineNo())
     addUInt(MDie, dwarf::DW_AT_decl_line, None, M->getLineNo());
   if (M->getIsDecl())
     addFlag(MDie, dwarf::DW_AT_declaration);
 
   return &MDie;
 }
 
 DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) {
   // Construct the context before querying for the existence of the DIE in case
   // such construction creates the DIE (as is the case for member function
   // declarations).
   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();
       // Build the decl now to ensure it precedes the definition.
       getOrCreateSubprogramDIE(SPDecl);
     }
   }
 

llvm/test/DebugInfo/X86/subprogram-across-cus.ll

+; RUN: llc %s -mtriple=x86_64-unknown-linux-gnu -filetype=obj -o %t
+; RUN: llvm-dwarfdump -verify %t
+; RUN: llvm-dwarfdump -debug-info %t | FileCheck %s
+; RUN: rm %t
+;
+;$ cat -n 1.cpp
+;     1  struct HHH;
+;     2  HHH *zzz;
+;
+;$ cat -n 2.cpp
+;     1  void __attribute__((optnone)) __attribute__((nodebug)) f1()  { }
+;     2
+;     3  struct HHH {
+;     4    template <typename bbb>
+;     5    static int __attribute__((always_inline)) ccc() {
+;     6      f1();
+;     7    }
+;     8  };
+;     9
+;    10  int main() {
+;    11    struct local { };
+;    12    HHH::ccc<local>();
+;    13  }
+;
+; $ clang -flto -O2 -g 1.cpp 2.cpp -o a.out
+;
+; Given this input, LLVM attempts to create a DIE for subprogram "main" in the
+; wrong context. The definition of struct "HHH" is placed in the CU for 1.cpp.
+; While creating the template instance in "HHH", function "ccc" is referenced
+; via the struct local type, and "main" is created in the CU for 1.cpp, which
+; is incorrect.
+;
+; See PR48790 for more discussion and original compile commands.
+;
+; Check that there are no verifier failures, and that the SP for "main" appears
+; in the correct CU.
+; CHECK-LABEL:      DW_TAG_compile_unit
+; CHECK:              DW_AT_name ("1.cpp")
+; CHECK-NOT:          DW_AT_name ("main")
+; CHECK-LABEL:      DW_TAG_compile_unit
+; CHECK:              DW_AT_name ("2.cpp")
+; CHECK:            DW_TAG_subprogram
+; CHECK:              DW_AT_name ("main")
+
+source_filename = "ld-temp.o"
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+; Function Attrs: noinline norecurse nounwind optnone uwtable mustprogress
+define internal fastcc void @_Z2f1v() unnamed_addr {
+entry:
+  ret void
+}
+
+; Function Attrs: norecurse noreturn nounwind uwtable mustprogress
+define dso_local i32 @main() local_unnamed_addr !dbg !17 {
+entry:
+  tail call fastcc void @_Z2f1v(), !dbg !21
+  unreachable, !dbg !21
+}
+
+!llvm.dbg.cu = !{!0, !9}
+!llvm.ident = !{!10, !10}
+!llvm.module.flags = !{!11, !12, !13, !14, !15, !16}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "clang version 12.0.0 ([e-mail]:llvm/llvm-project bc9ab9a5cd6bafc5e1293f3d5d51638f8f5cd26c)", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, globals: !3, splitDebugInlining: false, nameTableKind: None)
+!1 = !DIFile(filename: "1.cpp", directory: "/tmp/bees")
+!2 = !{}
+!3 = !{!4}
+!4 = !DIGlobalVariableExpression(var: !5, expr: !DIExpression())
+!5 = distinct !DIGlobalVariable(name: "zzz", scope: !0, file: !1, line: 2, type: !6, isLocal: false, isDefinition: true)
+!6 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64)
+!7 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "HHH", file: !8, line: 3, size: 8, flags: DIFlagTypePassByValue, elements: !2, identifier: "_ZTS3HHH")
+!8 = !DIFile(filename: "2.cpp", directory: "/tmp/bees")
+!9 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !8, producer: "clang version 12.0.0 ([e-mail]:llvm/llvm-project bc9ab9a5cd6bafc5e1293f3d5d51638f8f5cd26c)", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: None)
+!10 = !{!"clang version 12.0.0 ([e-mail]:llvm/llvm-project bc9ab9a5cd6bafc5e1293f3d5d51638f8f5cd26c)"}
+!11 = !{i32 7, !"Dwarf Version", i32 4}
+!12 = !{i32 2, !"Debug Info Version", i32 3}
+!13 = !{i32 1, !"wchar_size", i32 4}
+!14 = !{i32 1, !"ThinLTO", i32 0}
+!15 = !{i32 1, !"EnableSplitLTOUnit", i32 1}
+!16 = !{i32 1, !"LTOPostLink", i32 1}
+!17 = distinct !DISubprogram(name: "main", scope: !8, file: !8, line: 10, type: !18, scopeLine: 10, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !9, retainedNodes: !2)
+!18 = !DISubroutineType(types: !19)
+!19 = !{!20}
+!20 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!21 = !DILocation(line: 6, column: 5, scope: !22, inlinedAt: !27)
+!22 = distinct !DISubprogram(name: "ccc<local>", linkageName: "_ZN3HHH3cccIZ4mainE5localEEiv", scope: !7, file: !8, line: 5, type: !18, scopeLine: 5, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition | DISPFlagOptimized, unit: !9, templateParams: !24, declaration: !23, retainedNodes: !2)
+!23 = !DISubprogram(name: "ccc<local>", linkageName: "_ZN3HHH3cccIZ4mainE5localEEiv", scope: !7, file: !8, line: 5, type: !18, scopeLine: 5, flags: DIFlagPrototyped | DIFlagStaticMember, spFlags: DISPFlagOptimized, templateParams: !24)
+!24 = !{!25}
+!25 = !DITemplateTypeParameter(name: "bbb", type: !26)
+!26 = !DICompositeType(tag: DW_TAG_structure_type, name: "local", scope: !17, file: !8, line: 11, size: 8, flags: DIFlagFwdDecl)
+!27 = distinct !DILocation(line: 12, column: 3, scope: !17)