[Dwarf-discuss] Representing vtables in DWARF for downcasting

[Jeremy Morse]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20250425/b4a300dc/attachment.htm>