[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: virtual table layout on i386
From:       mrs () wrs ! com (Mike Stump)
Date:       1998-12-30 20:03:13
[Download RAW message or body]

> 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?

[prev in list] [next in list] [prev in thread] [next in thread]