>
> 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.
>
Ah, I didn't compile a large enough example to see that it's an index
rather than an offset.
> 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}}}
>
Now this is what the DWARF expression is supposed to look like.
It's odd to me that—in response to a bug report that complained that
finding the vtable pointer of an object was too much ABI knowledge for the
debuggers to handle—they implemented a buggy vtable_elem_location that
required even more detailed ABI knowledge!
> 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.
>
But the standard isn't even permissive here! It's very clear (from DWARF 2
on) that it should be an expression that evaluates to the location of the
vtable entry.
If the implementers had wanted to take advantage of a permissive standard,
they'd have been better advised to use a constant form for the vtable
element index. Such a usage could have easily been standardized after the
fact. (And it would have been more space efficient.)
-cary
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
