[Lldb-commits] [lldb] [lldb] Tolerate multiple compile units with the same DWO ID (PR #100577)

[Pavel Labath via lldb-commits]

================
@@ -97,12 +97,14 @@ void DWARFUnit::ExtractUnitDIEIfNeeded() {
         *m_dwo_id, m_first_die.GetOffset()));
     return; // Can't fetch the compile unit from the dwo file.
   }
-  // If the skeleton compile unit gets its unit DIE parsed first, then this
-  // will fill in the DWO file's back pointer to this skeleton compile unit.
-  // If the DWO files get parsed on their own first the skeleton back link
-  // can be done manually in DWARFUnit::GetSkeletonCompileUnit() which will
-  // do a reverse lookup and cache the result.
-  dwo_cu->SetSkeletonUnit(this);
+
+  // Link the DWO unit to this object, if it hasn't been linked already (this
+  // can happen when we have an index, and the DWO unit is parsed first).
+  if (!dwo_cu->LinkToSkeletonUnit(*this)) {
+    SetDwoError(Status::createWithFormat(
+        "multiple compile units with Dwo ID {0:x16}", *m_dwo_id));
----------------
labath wrote:

I don't think there's an easy way to do that. The problem is that the compile units aren't really empty (llvm already skips empty units). They could have arbitrarily many type definitions (typically enums, as those can't be homed) inside them, so we'd have to check if that's all they contain.

I've also thought about looking at the DW_AT_ranges attribute, but that doesn't cover variables, so we would misclassify compile units that only define variables.

The upshot of all this is that since the units don't contain any code, it's pretty hard (maybe impossible?) to actually end up "inside" them. Therefore, I'm not sure if the user would ever see this kind of error, and all that they'll do is slightly increase the error statistics (but then again, maybe we want this to show up in the statistics?)

What do you think?

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