This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/6830: Virtual table layout: wrong vcall/vbase order for primary base class
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: Grigory_Zagorodnev at vniief dot ims dot intel dot com, gcc-gnats at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nathan at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org
- Date: Wed, 03 Jul 2002 21:22:00 +0100
- Subject: Re: c++/6830: Virtual table layout: wrong vcall/vbase order for primary base class
- Organization: Codesourcery LLC
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6830
not a bug. You are misinterpreting the ABI spec.
(you do know about the -fdump-class-hierarchy flag don't you?) Anyway.
The V::g thunk in S's vtable uses a vcall offset that you should consider
part of S's vtable (not P's, the overridden class). So the vcall offset
is at a lower index than the vbase offsets.
This is the bit from 2.5.2 in the ABI (my emphasis)
Virtual call (vcall) offsets are used to perform ... These entries are
allocated in the virtual table for the *virtual* base class that is *most
immediately derived* from the base class containing the overridden.
Here the most immediately derived virtual base on the path from P->S->V is S.
The (ia32) vtable for V is and should be
12 vbase offset V to R
4 vbase offset V to S
0 offset to top
TI type info
.... primary vptr here
v::g final overrider
... start of secondary vtable (that for S)
-4 vcall offset (to V) for V::g thunk
8 vbase offset S to R
-4 offset to top
TI type info
vthunk(-4) to V::g
nathan
--
Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org