[lldb] [llvm] Add support for using foreign type units in .debug_names. (PR #87740)

[Alexander Yermolovich via llvm-commits]

================
@@ -273,6 +301,44 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
     if (!isType(entry.tag()))
       continue;
 
+
+    DWARFTypeUnit *foreign_tu = GetForeignTypeUnit(entry);
+    if (foreign_tu) {
+      // If this entry represents a foreign type unit, we need to verify that
+      // the type unit that ended up in the final .dwp file is the right type
+      // unit. Type units have signatures which are the same across multiple
+      // .dwo files, but only one of those type units will end up in the .dwp
+      // file. The contents of type units for the same type can be different
+      // in different .dwo file, which means the DIE offsets might not be the
+      // same between two different type units. So we need to determine if this
+      // accelerator table matches the type unit in the .dwp file. If it doesn't
+      // match, then we need to ignore this accelerator table entry as the type
+      // unit that is in the .dwp file will have its own index.
+      const llvm::DWARFDebugNames::NameIndex *name_index = entry.getNameIndex();
+      if (name_index == nullptr)
+        continue;
+      // In order to determine if the type unit that ended up in a .dwp file
+      // is valid, we need to grab the type unit and check the attribute on the
+      // type unit matches the .dwo file. For this to happen we rely on each
+      // .dwo file having its own .debug_names table with a single compile unit
+      // and multiple type units. This is the only way we can tell if a type
+      // unit came from a specific .dwo file.
----------------
ayermolo wrote:

> Sounds like this wouldn't work for a merged `.debug_names` table? Could you leave a FIXME/do you plan to fix this? Oh, it also wouldn't work for any kind of LTO which could have multiple CUs in a single object file/dwo file.
> 
> (FYI @cmtice )

Does "multiple cus" in .o/dwo actually happen? 
>From spec perspective I don't understand how this will work. Skeleton CU points to .o/dwo which then has multiple cus? What does it mean?

https://github.com/llvm/llvm-project/pull/87740