[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.16.3 Specification of thunked vtables

For vtable thunks, each slot only consists of a pointer to the virtual function, which might be a thunk function. The first slot in the vtable is an offset of the this pointer to the complete object, which is needed as a parameter to __dynamic_cast. The second slot is the virtual typeinfo function. All other slots are allocated with the same procedure as in the non-thunked case. Allocation of vfields also uses the same procedure as described above.

If the virtual function needs an adjusted this pointer, a thunk function is emitted. If supported by the target architecture, this is only a half-function. Such a thunk has no stack frame; it merely adjusts the first argument of the function, and then directly branches into the implementation of the virtual function. If the architecture does not support half-functions (i.e. if ASM_OUTPUT_MI_THUNK is not defined), the compiler emits a wrapper function, which copies all arguments, adjust the this pointer, and then calls the original function. Since objects of non-aggregate type are passed by invisible reference, this copies only POD arguments. The approach fails for virtual functions with a variable number of arguments.

In order to support the vtables needed in base constructors with pvbases, the compiler passes an implicit __vlist argument as described above, if the version 2 thunks are used. For version 1 thunks, the base class constructor will fill in the vtables for the complete base class, which will incorrectly adjust the this pointer, leading to a dynamic error.



This document was generated by system on December, 2 2004 using texi2html