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

[David Mentler 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;
----------------
mentlerd wrote:

https://github.com/llvm/llvm-project/pull/210584/commits/6084c421190c3072733e35370179344f3d55e225 - Turns out simple solutions are still superior :) 

I have dropped trying to reason about `vtableBase` in favour of trusting that the vtable symbol has it's base address correctly set. This solves the shortcomings with virtual inheritance.

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