Re: virtual table layout on i386

Re: virtual table layout on i386

[Mike Stump]

> Date: Tue, 29 Dec 1998 11:29:09 -0600
> From: adriang@campbellsoft.com
> To: egcs@egcs.cygnus.com

> Can anyone elaborate on the 'just one change (for thunks)'?
> (mentioned towards the end of the message)

Sure, some systems are migrating to use thunks (glibc 2.x linux), you
can find out either by reading all the tm.h files, or compiling up a
testcase and looking at it.  At some point, we will mass migrate all
the rest that make sense.  I don't have enough performance numbers to
know if we should do it on all machines, or a subset of them.  I just
checked the source, and Jason plans on turning them on the next time
we break the abi.

This change compacted the vtable, as vtable elements go from 8 (or 12
bytes) to 4 bytes.  This was the first change in long time that was
incompatible.  There was a pror change when we got rtti in, but we
killed the size entry that was in the vtable in the first slot
previously, and just reused it for the rtti pointer.  So, technically,
you would not have been hit by this change, only rtti or size players
would have been.

If your question is what is the nature of the vtable or what is a
thunk, this is a bit beyond what I want to write...  For vtable, see
ARM, for thunks, the delta is stored implicitly in the pointer to
function in the vtable, as the code the pointer points to does an
adjustment of the this pointer, then jumps to the thunked function.
We also employ the trivial optimization that is the delta is 0, we
just use the thunked function directly.

> Also, I identified two 'reserved' slots in the vtable

Yes, but that doesn't mean there are two.  :-) I didn't want to
correct you before because my linux machine was down and I didn't want
to build up another compiler on the spot.  Well, it online now, and we
see that you must have an older linux glibc system...

_vt.1A:
        .value 0
        .value 0
        .long __tf1A
        .value 0
        .value 0
        .long foo__1A

Here we see foo, the first virtual, and tf for A.  The entries are 8
bytes, the first slot (entry) is rtti, and the second is foo.  If
you're going to ask what the 0s are, I'll just say, see the ARM and
welcome to C++.  The first two really are unused, though.

> Does rtti use both slots? If no, what is the second one for?

Re: virtual table layout on i386

[adriang]

Can anyone elaborate on the 'just one change (for thunks)'? (mentioned towards
the end of the message)
Also, I identified two 'reserved' slots in the vtable and I understand that at
least one is used for rtti. Does rtti use both slots? If no, what is the second
one for?
thanx

> Date: Tue, 22 Dec 1998 08:08:53 -0600 (EST)
> From: 
> To: egcs@egcs.cygnus.com

> I'm on Linux on Intel processor. I noticed that the virtual table
> has the first two slots reserved, the first virtual function that I
> include in the class, occupying third position (offset 8). Question:
> what are the first two slots reserved for (rtti? virt
> destructor?). How likely is it to change in egcs?

If you consider it 100% likely, you will be able to write portable
code and not get burned.  The second you start guessing and assuming
things about the vtable layout, you will get burned.  You can write
non-portable code, if you wish, you assume the responsibility and
liability.  Having said that, the format has virtually been fixed for
a decade, with just one change (for thunks).

Yes, the `extra' slot at the front is for rtti.

Re: virtual table layout on i386

[Mike Stump]

> Date: Tue, 22 Dec 1998 08:08:53 -0600 (EST)
> From: <adriang@adriang.ce.mediaone.net>
> To: egcs@egcs.cygnus.com

> I'm on Linux on Intel processor. I noticed that the virtual table
> has the first two slots reserved, the first virtual function that I
> include in the class, occupying third position (offset 8). Question:
> what are the first two slots reserved for (rtti? virt
> destructor?). How likely is it to change in egcs?

If you consider it 100% likely, you will be able to write portable
code and not get burned.  The second you start guessing and assuming
things about the vtable layout, you will get burned.  You can write
non-portable code, if you wish, you assume the responsibility and
liability.  Having said that, the format has virtually been fixed for
a decade, with just one change (for thunks).

Yes, the `extra' slot at the front is for rtti.

virtual table layout on i386

[adriang]

I'm on Linux on Intel processor. I noticed that the virtual table has
the first two slots reserved, the first virtual function that I include in
the class, occupying third position (offset 8). Question: what are the
first two slots reserved for (rtti? virt destructor?). How likely is
it to change in egcs?