[Lldb-commits] [lldb] [lldb] Fallback to `__clang_vtable` for robust dynamic type resolution (PR #210584)

[Michael Buch via lldb-commits]

================
@@ -14,13 +14,68 @@
 #include "lldb/Expression/FunctionCaller.h"
 #include "lldb/Utility/LLDBLog.h"
 
+#include "lldb/Symbol/VariableList.h"
+#include "lldb/ValueObject/ValueObjectVariable.h"
+
 using namespace lldb;
 using namespace lldb_private;
 
 static const char *vtable_demangled_prefix = "vtable for ";
 
 ItaniumABIRuntime::ItaniumABIRuntime(Process *process) : m_process(process) {}
 
+/// clang emits a `DW_TAG_variable` called `__clang_vtable` inside the
+/// enclosing class this function uses that to resolve the dynamic type of
+/// `in_value`
+TypeAndOrName ItaniumABIRuntime::FindTypeInfoWithClangVTable(
+    ValueObject &in_value,
+    const LanguageRuntime::VTableInfo &vtable_info) const {
+  ModuleSP module_sp = vtable_info.symbol->CalculateSymbolContextModule();
+  if (!module_sp)
+    return TypeAndOrName();
+
+  auto vptr = vtable_info.addr.GetLoadAddress(&m_process->GetTarget());
+
+  // NOTE: vptr points at the 'address point', not the vtable itself
+  auto vtable = vptr - m_process->GetAddressByteSize() * 2;
+
+  VariableList vars;
+
+  // SymbolFile doesn't provide an API to lookup a global variable with a
+  // specific location, so we have to resort to an unbounded name lookup
+  module_sp->FindGlobalVariables(ConstString("__clang_vtable"),
+                                 CompilerDeclContext(), -1, vars);
+
+  Log *log = GetLog(LLDBLog::Object);
+  LLDB_LOGF(log, "0x%16.16" PRIx64 ": found %zu __clang_vtable variables\n",
+            in_value.GetPointerValue().address, vars.GetSize());
+
+  for (lldb::VariableSP var : vars) {
+    auto valobj = ValueObjectVariable::Create(m_process, var);
+    if (valobj->GetLoadAddress() != vtable)
+      continue;
+
+    auto type_sp = var->GetEnclosingType();
+    if (!type_sp)
+      continue;
+
+    if (!TypeSystemClang::IsCXXClassType(type_sp->GetForwardCompilerType()))
+      continue;
----------------
Michael137 wrote:

Wouldn't this be more of a producer bug? I.e., generating a `__clang_vtable` that points to a non-c++ type?

Seems ok to be defensive about it. But maybe we should log it. Probably don't even need the continue and can just bail?

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