Deciphering vtable dumps

Question

I am "playing" with virtual inheritance in C++, and I want to know how a class object is laid out. I have those three classes:

class A {
private:
    int a;
public:
    A() {this->a = 47;}
    virtual void setInt(int x) {this->a = x;}
    virtual int getInt() {return this->a;}
    ~A() {this->a = 0;}
};

class B {
private:
    int b;
public:
    B() {b = 48;}
    virtual void setInt(int x) {this->b = x;}
    virtual int getInt() {return this->b;}
    ~B() {b = 0;}
};

class C : public A, public B {
private:
    int c;
public:
    C() {c = 49;}
    virtual void setInt(int x) {this->c = x;}
    virtual int getInt() {return this->c;}
    ~C() {c = 0;}
};

(I think they are correct :p)

I used -fdump-class-hierarchy with g++, and I got this

Vtable for A
A::_ZTV1A: 4u entries
0     (int (*)(...))0
8     (int (*)(...))(& _ZTI1A)
16    A::setInt
24    A::getInt

Class A
   size=16 align=8
   base size=12 base align=8
A (0x10209fb60) 0
    vptr=((& A::_ZTV1A) + 16u)

Vtable for B
B::_ZTV1B: 4u entries
0     (int (*)(...))0
8     (int (*)(...))(& _ZTI1B)
16    B::setInt
24    B::getInt

Class B
   size=16 align=8
   base size=12 base align=8
B (0x1020eb230) 0
    vptr=((& B::_ZTV1B) + 16u)

Vtable for C
C::_ZTV1C: 8u entries
0     (int (*)(...))0
8     (int (*)(...))(& _ZTI1C)
16    C::setInt
24    C::getInt
32    (int (*)(...))-0x00000000000000010
40    (int (*)(...))(& _ZTI1C)
48    C::_ZThn16_N1C6setIntEi
56    C::_ZThn16_N1C6getIntEv

Class C
   size=32 align=8
   base size=32 base align=8
C (0x1020f5080) 0
    vptr=((& C::_ZTV1C) + 16u)
  A (0x1020ebd90) 0
      primary-for C (0x1020f5080)
  B (0x1020ebe00) 16
      vptr=((& C::_ZTV1C) + 48u)

Now what the heck are those (int (*)(...))-0x00000000000000010 and C::_ZThn16_N1C6setIntEi and (int (*)(...))0?? Can someone explain the dump?

Thank you.

Its undefined. Every compiler (and even versions of the compiler) do it differently. — Martin York, Jan 05 '11 at 22:15
You can use c++filt to decode `_ZTI1C` The others are locations probably be filled by some later stage in the compiler with function pointers. — Martin York, Jan 05 '11 at 22:20

score 7 · Accepted Answer · answered Jan 05 '11 at 22:16

I'm not 100% sure that this answer is correct, but here's my best guess.

When you have a class that inherits multiply and non-virtually, the layout of the class is usually a complete object of the first base type, then a complete object of the second base type, then the data for the object itself. If you look at B, you can see the vtable pointer for the A object, and if you look at C you can see that there's pointers into the vtable for both the A and B objects.

Because the objects are laid out this way, it means that if you have a B* pointer pointing at a C object, the pointer will actually not be at the base of the object; rather it will be pointing somewhere in the middle. This means that if you ever need to cast the object to an A*, you'll need to adjust the B* pointer some amount to skip it back to the start of the object. In order to do this, the compiler needs to encode somewhere the number of bytes you need to skip back to get to the start of the object. I think that the very first (int(*)(...)) is actually just a raw number of bytes you need to look at to get to the start of the object. If you'll notice, for the A vtable this pointer is 0 (since the vtable for A is at the start of the object, and the same is true for the B vtable (since it also lives at the start of the object. However, notice that the C vtable has two parts - the first part is the vtable for A, and its first crazy entry is zero as well (since if you're at the A vtable, you don't need to do any adjustments). However, after the first half of this table is what appears to be the B vtable, and notice that its first entry is hex value -0x10. If you look at the C object layout, you'll notice that the B vtable pointer is 16 bytes after the A vtable pointer. This -0x10 value might be the corrective offset you need to skip back over the B vtable pointer to get back to the root of the object.

The second crazy entry of each vtable seems to be a pointer to the vtable itself. Notice that it's always equal to the address of the vtable object (compare the name of the vtable and what it's pointing at). This would be necessary if you wanted to do any sort of runtime type identification, since that usually involves looking at the address of the vtable (or at least something near the front of it).

Finally, as for why there's the cryptically-named setInt and getInt functions at the end of the C vtable, I'm pretty sure that's because the C type inherits two different sets of functions named setInt and getInt - one through A and one through B. If I had to guess, the mangling here is to ensure that the compiler internals can differentiate between the two virtual functions.

Hope this helps!

On the first number `-0x10`, I also thought of that as the offset of the subobject within the final object. On why that would be there... I don't quite agree in your reasoning, as the compiler is seeing all class definitions when it performs the casts (whether implicit or explicit), so it is not a hint to the compiler. Then I thought of other possible reasons, and the only thing I can think of is so that when deleting through a pointer to `B`, the compiler can get a pointer to the beginning to release the memory. But I am unsure of that. — David Rodríguez - dribeas, Jan 05 '11 at 22:47
On the second entries, those are most probably not pointers into the vtable's but rather pointers into the typeinfo object associated with that particular instance. Note the concrete values: `A::_ZTV1A` vs `_ZTI1A`, and that vptr in the `A` object is set to be `(& A::_ZTV1A - 16u)`... they do not coincide. — David Rodríguez - dribeas, Jan 05 '11 at 22:51
Those are both very good points. I'm pretty sure that you're correct on both counts. — templatetypedef, Jan 05 '11 at 22:58

score 6 · Answer 2 · answered Jan 05 '11 at 22:37

Here's your dump ran through c++filt:

Vtable for A
A::vtable for A: 4u entries
0     (int (*)(...))0
8     (int (*)(...))(& typeinfo for A)
16    A::setInt
24    A::getInt

Class A
   size=16 align=8
   base size=12 base align=8
A (0x10209fb60) 0
    vptr=((& A::vtable for A) + 16u)

Vtable for B
B::vtable for B: 4u entries
0     (int (*)(...))0
8     (int (*)(...))(& typeinfo for B)
16    B::setInt
24    B::getInt

Class B
   size=16 align=8
   base size=12 base align=8
B (0x1020eb230) 0
    vptr=((& B::vtable for B) + 16u)

Vtable for C
C::vtable for C: 8u entries
0     (int (*)(...))0
8     (int (*)(...))(& typeinfo for C)
16    C::setInt
24    C::getInt
32    (int (*)(...))-0x00000000000000010
40    (int (*)(...))(& typeinfo for C)
48    C::non-virtual thunk to C::setInt(int)
56    C::non-virtual thunk to C::getInt()

Class C
   size=32 align=8
   base size=32 base align=8
C (0x1020f5080) 0
    vptr=((& C::vtable for C) + 16u)
  A (0x1020ebd90) 0
      primary-for C (0x1020f5080)
  B (0x1020ebe00) 16
      vptr=((& C::vtable for C) + 48u)

No idea what the (int (*)(...))-0x00000000000000010 and (int (*)(...))0 are.
The C::_ZThn16_N1C6setIntEi/C::non-virtual thunk to C::setInt(int) part is an "optimization of virtual function calls in the presence of multiple or virtual inheritance" as described here.

+1 Beat me to it :) This is the only part of the question I had clear --it is simple if you get both the class dump and the assembly: offset the `this` pointer by 16 and jump to `setInt/getInt` (in each case) — David Rodríguez - dribeas, Jan 05 '11 at 23:01
@David: if any other parts become clear please add them to the answer. — Eugen Constantin Dinca, Jan 06 '11 at 02:31
what's the difference between virtual thunk and non-virtual thunk? — choxsword, May 15 '18 at 02:08

Deciphering vtable dumps

2 Answers2

Linked