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
