On Wed, Apr 23, 2025 at 8:45 AM Michael Buch <michaelbuc...@gmail.com> wrote:
>
> Sounds like this is what
> https://github.com/llvm/llvm-project/pull/130255 is trying to achieve?
Yes, though that may be trying to achieve other things too (there's
some discussion of trying to go from the class definition in the DWARF
to the vtable pointer which I haven't considered and don't immediately
see a use case for).
- Kyle
> If we could simplify that part of LLDB that'd be great!
>
> On Wed, 23 Apr 2025 at 16:32, Kyle Huey via Dwarf-discuss
> <dwarf-discuss@lists.dwarfstd.org> wrote:
> >
> > Consider the following C++ program
> >
> > #include <stdio.h>
> >
> > class Base {
> > public:
> > virtual const char* method1() = 0;
> > void method2() {
> > printf("%s\n", method1());
> > }
> > };
> >
> > class DerivedOne : public Base {
> > virtual const char* method1() override {
> > return "DerivedOne";
> > }
> > };
> >
> > template<typename T>
> > class DerivedTwo : public Base {
> > public:
> > DerivedTwo(T t) : t(t) {}
> > private:
> > virtual const char* method1() override {
> > return t;
> > }
> > T t;
> > };
> >
> > template<typename T>
> > class DerivedThree : public Base {
> > public:
> > DerivedThree(T t) : t(t) {}
> > private:
> > virtual const char* method1() override {
> > return t();
> > }
> > T t;
> > };
> >
> > int main() {
> > DerivedOne d1;
> > DerivedTwo d2("DerivedTwo");
> > DerivedThree d3([]() {
> > return "DerivedThree";
> > });
> > d1.method2();
> > d2.method2();
> > d3.method2();
> > return 0;
> > }
> >
> > If a debugger stops at method1, the DW_TAG_formal_parameter will tell
> > the debugger the type of `this` is Base. Downcasting to the derived
> > type is very useful for the programmer though, so both gdb and lldb
> > contain a feature to downcast based on the vtable pointer (the "print
> > object" and the "target.prefer-dynamic" settings in the respective
> > debuggers).
> >
> > The first part of this is straightforward. The DWARF for Base will
> > contain a member for the vtable pointer, and that plus knowledge of
> > how the ABI lays out vtables allows the debugger to effectively do a
> > dynamic_cast<void*> to obtain a pointer to the most derived object.
> > From there the vtable address is compared against the ELF symbol table
> > to find the mangled name of the vtable symbol.
> >
> > Then things begin to get hairy, the debugger demangles the mangled
> > name that exists in the ELF symbol table, chops off the "vtable for "
> > prefix on the demangled name, and searches for the type by name in the
> > DWARF. If it finds the type, it adjusts the type of the value and
> > prints it accordingly. But this text based matching doesn't always
> > work. There are no mangled names for types so the debugger's
> > demangling has to match the compiler's output character for character.
> >
> > In the example program I've provided, when using the respective
> > compilers, gdb can successfully downcast DerivedOne and DerivedThree
> > but not DerivedTwo. gdb fails because gcc emits the DW_TAG_class_type
> > with a DW_AT_name "DerivedTwo<main()::<lambda()> >" but libiberty
> > demangles the vtable symbol to "vtable for
> > DerivedTwo<main::{lambda()#1}>" and those do not match. lldb can only
> > successfully downcast DerivedOne. lldb appears to not handle classes
> > with template parameters correctly at all. And even if all of that
> > were fixed, libiberty and llvm disagree about how to demangle the
> > symbol for DerivedTwo's vtable, so the two ecosystems would not be
> > interoperable.
> >
> > Perhaps these are merely quality of implementation issues and belong
> > on the respective bug trackers, however, better representations are
> > possible. Rustc, for example, does not rely on the ELF symbol table
> > and demangled string matching. It emits a global variable in the DWARF
> > whose location is the address of the vtable. That variable has a
> > DW_AT_type pointing to a DW_TAG_class_type that describes the layout
> > of the vtable, and that type has a DW_AT_containing_type that points
> > to the type making use of that vtable.
> >
> > Any thoughts?
> >
> > - Kyle
> > --
> > Dwarf-discuss mailing list
> > Dwarf-discuss@lists.dwarfstd.org
> > https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
