[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.