On 4/23/25 22:46, Cary Coutant via Dwarf-discuss wrote:
Looking at the DWARF generated by GCC (and I'm guessing LLVM does the same), I
see vtable_elem_location attributes that look like this:
<1b8> DW_AT_vtable_elem_location: 2 byte block: 10 0 (DW_OP_constu: 0)
This is not correct DWARF! It's supposed to be a location description, and this
is merely a DWARF expression that evaluates to an offset relative to the vtable
pointer. The description of the attribute says that address of an object of the
enclosing type is pushed onto the expression stack, so there really ought to be
a DW_OP_deref to get the vtable pointer on the stack, followed by the
DW_OP_constu and DW_OP_add.
Actually, for GCC and LLVM, the location is an index into vtable, not an
offset. We have a compiler abstraction that knows how to convert the DWARF
DW_AT_vtable_elem_location to our internal representation of a location,
because various compilers generate the DWARF differently and the contents of
the vtable vary by target architecture. For example, on AIX and 64-bit
Linux-Power, the vtable slot contains a pointer to a TOC entry, which in turn
contains the pointer to the function followed by the TOC value for the function.
Here's a simple example for a program compiled with Clang on Linux-x86_64.
The DWARF for a virtual function is:
0x000007aa: DW_TAG_subprogram
DW_AT_linkage_name ("_ZN1A3gooEv")
DW_AT_name ("goo")
DW_AT_decl_file ("/.../tx_c++11_virtual.cxx")
DW_AT_decl_line (8)
DW_AT_virtuality (DW_VIRTUALITY_virtual)
DW_AT_vtable_elem_location (DW_OP_constu 0x1)
DW_AT_declaration (true)
DW_AT_external (true)
DW_AT_containing_type (0x0000077d "A")
And here is the internal location we created for that virtual function:
{location {{indirect} {ldc 1} {ldc 8} {mul} {plus}}}
When that location is eventually used, the value of the vtable pointer is first
pushed onto the location evaluation stack, and then the above location is
resolved. The result is the location of the pointer to the function.
On AIX, for GCC, we build a location with an extra indirection through the TOC
pointer to get to location of the function pointer in the TOC entry (which just
happens to be at offset 0):
{location {{indirect} {ldc 1} {ldc 8} {mul} {plus} {indirect}}}
So, in practice, handling DW_AT_vtable_elem_location is both highly compiler
and platform dependent. I guess that's what you should expect with a permissive
standard.
Cheers, John D.
This e-mail may contain information that is privileged or confidential. If you
are not the intended recipient, please delete the e-mail and any attachments
and notify us immediately.
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
