I've written a three-part proposal to address these issues:
- The first part, 250506.1 <https://dwarfstd.org/issues/250506.1.html>,
proposes a standard mechanism for locating the virtual function table
(vtable) given an object of a polymorphic class.
- The second part, 250506.2 <https://dwarfstd.org/issues/250506.2.html>,
proposes a standard mechanism for identifying the most-derived class of an
object, given its vtable location, in order to support downcasting of
pointers while debugging.
- The third part, 250506.3 <https://dwarfstd.org/issues/250506.3.html>,
proposes a fix to the DW_AT_vtable_elem_location attribute, which
appears to be incorrectly implemented in compilers today.
-cary
On Fri, May 2, 2025 at 1:31 PM Todd Allen via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> FWIW, when we at Concurrent were in the compiler business, our C++
> compilers generated two vendor-defined attributes, both hanging off the
> DW_TAG_{structure,class}_type. Here are a couple with some sample
> locations:
>
> DW_AT_vtable_location [DW_OP_plus_uconst 0; DW_OP_deref]
> DW_AT_type_vtable_location [DW_OP_addr 0x12345678]
>
> The first was a description of how to obtain the address of the vtable tag
> from an object.
> The second was a description of the address of the vtable tag from just
> the type.
>
> As we characterized them internally, they didn't have to be the address of
> the vtable proper. They just had to be something that could be compared as
> a positive identification of the actual type. I believe they always were
> the actual vtable addresses, though. Because why not?
>
> We do still have logic in our debugger to use them, too. In addition to
> the mangling-based approaches.
>
> It does require walking the whole DWARF tree to find them.
>
> Todd
>
> On 4/25/25 09:49, Jeremy Morse via Dwarf-discuss wrote:
>
> Hi all,
>
> The LLVM discussion linked [0] happens to be us Sony folks, and it's
> supporting the use-case Kyle described of automatic downcasting, i.e.
> identifying the most-derived-class of an object from its vtable pointer.
> Having to demangle the symbol table is a real pain (Tom, CC'd knows more)
> especially with things like anonymous namespaces.
>
> Right now the approach is to have a top-level nameless global variable
> with the location set to the vtable address, and a DW_AT_specification
> linking into the class definition:
>
> 0x00000082: DW_TAG_variable
> DW_AT_specification (0x000000b6 "_vtable$")
> DW_AT_alignment (8)
> DW_AT_location (DW_OP_addrx 0x1)
>
> [Then deeper into the DIE tree,]
>
> 0x0000008b: DW_TAG_structure_type
> DW_AT_containing_type (0x00000034 "CBase")
> DW_AT_calling_convention (DW_CC_pass_by_reference)
> DW_AT_name ("CDerived")
> DW_AT_decl_file ("vtables.cpp")
> DW_AT_decl_line (6)
>
> [...]
>
> 0x000000b6: DW_TAG_variable
> DW_AT_name ("_vtable$")
> DW_AT_type (0x00000081 "void *")
> DW_AT_external (true)
> DW_AT_declaration (true)
> DW_AT_artificial (true)
> DW_AT_accessibility (DW_ACCESS_private)
>
> This works well enough for our own debugger use-cases; I agree with Cary
> that it's hacky to rely on the name of a variable to signify important
> information like this and an officially blessed way could help.
>
> I've no opinion on the DW_AT_vtable_elem_location behaviours, although
> we can consider it a separate issue.
>
> [0] https://github.com/llvm/llvm-project/pull/130255
>
> --
> Thanks,
> Jeremy
>
>
>
> --
> 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
