[Bug default/28642] vtable offset position seems wrong

["woodard at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28642

--- Comment #3 from Ben Woodard <woodard at redhat dot com> ---
it appears in the DWARF that clang explicitly provides the vtable offset using
the DW_AT_vtable_elem_location for the function but GCC relies on the C++ABI
rules to layout the vtable and so the element location in the vtable is
inferred rather than being specified.

So it appears like when libabigail doesn't get an explicit vtable_element it
sets its position to -1 which is 0xFFFF FFFF FFFF FFFF 18446744073709551615 for
a 64b int in twos compliment.

There is some trickiness to inferring the vtable position of a particular
function. It is by order of declaration in the class declaration. Quoting the
C++ABI section 2.5.2
http://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-components

"The order of the virtual function pointers in a virtual table is the order of
declaration of the corresponding member functions in the class. If an
implicitly-declared copy assignment operator, move assignment operator, or
destructor is virtual, it is treated as if it were declared at the end of the
class, in that order. (Implicitly-declared assignment operators may be virtual
if a base class declares a virtual assignment operator taking a reference to a
derived class type.)" 

Unless I am missing something, it would seem like this logic would have to be
implemented in libabigail to ensure that the vtable order is right.

-- 
You are receiving this mail because:
You are on the CC list for the bug.