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
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
