deciphering vtable dumps

问题

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.

回答1:

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!

回答2:

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.

来源：https://stackoverflow.com/questions/4609631/deciphering-vtable-dumps

标签

c++

inheritance

dump

class-hierarchy