[Dwarf-discuss] Representing vtables in DWARF for downcasting

[Ben Woodard]

Can unions have virtual functions and thus vtables? My understanding is 
that unions can have member functions but I can't see how they can have 
virtual functions? What function would you call? Where would you put the 
vtable pointer?

This article on C++ reference suggests that they cannot have virtual 
functions at the source level 
https://en.cppreference.com/w/cpp/language/union#:~:text=A%20union%20can%20have%20member,have%20a%20default%20member%20initializer. 
and I can't see how a union with a vtable could be implemented.

So I think "A structure, union, or class type may have a 
DW_AT_vtable_location attribute," should only be "A structure, or class..."

-ben

On 5/6/25 6:19 PM, Cary Coutant via Dwarf-discuss wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20250507/9ceeae00/attachment-0001.htm>