再议内存布局,你学会了吗?

开发 前端
由于不同的基类起点可能处于不同的位置,因此当需要将它们转化为实际类型时,this指针的偏移量也不相同,且由于多态的特性,b2的实际类型在编译时期是无法确定的;那必然需要一个东西帮助我们在运行时期确定b2的实际类型,这个东西就是offset_to_top​。

你好,我是雨乐!

在上一篇文章C++:从技术角度聊聊RTTI中聊到了虚函数表,以及内部的部分布局。对于c++对象的内存布局一直处于似懂非懂似清非清的阶段,没有去深入了解过,所以借着这个机会,一并分析下。

多态在我们日常工作中用的算是比较多的一种特性,业界编译器往往是通过虚函数来实现运行时多态,而涉及到虚函数的内存布局往往是最麻烦且容易出错的,本文从一个简单的例子入手,借助gcc和gdb,对内存布局进行分析,相信看完本文,对内存布局会有一个清晰的认识。

多态

众所周知,C++为了实现多态(运行期),引进了虚函数(语言标准支持的,其它实现方式不在本文讨论范围内),而虚函数的实现机制则是通过虚函数表。这块的知识点不算多,却非常重要,因此往往是面试必问之一,当然,对于我也不例外。作为候选人,如果没有把运行期多态的实现机制讲清楚,那么此次面试基本凉凉~~

仍然以上一篇文章的代码为例,代码如下:

class Base1 {
public:
virtual void fun() {}
virtual void f1() {}
int a;
};

class Derived : public Base {
public:
void fun() {} // override Base::fun()
int b;
};

void call(Base *b) {
b->fun();
}

在上述示例call()函数中,当b指向Base对象时候,call()函数实际调用的是Base::fun();当b指向Derived对象时候,call()函数实际调用的是Derived::fun()。之所以可以这么实现,是因为虚函数后面的实现机制--虚函数表(后面称为Vtable):

• 对于每个类(存在虚函数,后面文中不再赘述),存在一个表,表的内容包含虚函数等(不仅仅是虚函数,在后面会有细讲),类似于如下这种:

vtable_Base = {&Base::func, ...}
vtable_Derived = {&Derived::func, ...}

• 在创建类对象时候,对象最前部会有一个指针(称之为vptr),指向给类虚函数表的对应位置。PS:(需要注意的是并不是指向Vtable的头,这块一定要注意)

那么,call()函数在运行的时候,因为不知道其参数b所指向具体类型是什么,所以只能通过其它方式进行调用。在前面的内容中,有提到过每个对象会有一个指针指向其类的虚函数表,那么就可以通过该虚函数表进行相应的调用。因此,call()函数中的b->fun()就类似于如下:

((Vtable*)b)[0]()

在现在编译器对多态的实现中,原理与上述差不多,只是更为复杂。比如在在虚函数指针的索引(如上述例子中的index 0),这个index是根据函数的声明顺序而来,如果在Derived中再新增一个virtual函数fun2(),那么其在虚函数表中的index就是1。

实现

本节中以一个多继承作为示例,代码如下:

class Base1 {
public:
void f0() {}
virtual void f1() {}
int a;
};

class Base2 {
public:
virtual void f2() {}
int b;
};

class Derived : public Base1, public Base2 {
public:
void d() {}
void f2() {} // override Base2::f1()
int c;
};

int main() {
Base2 *b2 = new Base2;
Derived *d = new Derived;
}

后面的内容将分别从基类和派生类的角度进行分析。

基类

首先,我们通过g++的命令-fdump-class-hierarchy进行编译,以便在布局上有一个宏观的认识,然后通过gdb进行更加详细的分析。

Base2内存布局如下:

Vtable for Base2
Base2::_ZTV5Base2: 3u entries
0 (int (*)(...))0
8 (int (*)(...))(& _ZTI5Base2)
16 (int (*)(...))Base2::f2

Class Base2
size=16 align=8
base size=12 base align=8
Base2 (0x0x7ff572e6b600) 0
vptr=((& Base2::_ZTV5Base2) + 16u)

在上述代码中,Base2的Vtable名为 _ZTV5Base2 ,经过c++filt处理之后,发现其为vtable for Base2。之所以是这种是因为被编译器进行了mangled。其中,TV代表Table for Virtual,后面的数字5是类名的字符数,Base2则是类名。

维基百科以g++3.4.6为示例,示例中之处Vtable应该只包含指向Base2::f2 的指针,但在我的本地环境(g++5.4.0,布局如上述)中,B2::f2为第三行:首先是offset,其值为0;然后包含一个指向名为_ZTI5Base2的结构的指针(这个在上节RTTI一文中有讲,在本文后面也会涉及);最后是函数指针B2::f2。

g++ 3.4.6 from GCC produces the following 32-bit memory layout for the object b2:[nb 1]

b2:  +0: pointer to virtual method table of Base2  +4: value of bvirtual method table of B2:  +0: Base2::f2()   

继续看Class Base2部分,我们注意到有一句vptr=((& Base2::_ZTV5Base2) + 16u),通过这句可以知道,Base2类中其虚函数指针vptr指向其虚函数表的首位+16处。

在下面的内容中,将通过gdb来分析其内存布局。

(gdb) disas
Dump of assembler code for function main:
0x00000000004006f8 <+0>: push %rbp
0x00000000004006f9 <+1>: mov %rsp,%rbp
0x00000000004006fc <+4>: push %rbx
0x00000000004006fd <+5>: sub $0x18,%rsp
=> 0x0000000000400701 <+9>: mov $0x10,%edi
0x0000000000400706 <+14>: callq 0x400578 <_Znwm@plt>
0x000000000040070b <+19>: mov %rax,%rbx
0x000000000040070e <+22>: mov %rbx,%rdi
0x0000000000400711 <+25>: callq 0x40076a <_ZN5Base2C2Ev>
0x0000000000400716 <+30>: mov %rbx,-0x18(%rbp)
0x000000000040071a <+34>: mov $0x20,%edi
0x000000000040071f <+39>: callq 0x400578 <_Znwm@plt>
0x0000000000400724 <+44>: mov %rax,%rbx
0x0000000000400727 <+47>: mov %rbx,%rdi
0x000000000040072a <+50>: callq 0x40079a <_ZN7DerivedC2Ev>
0x000000000040072f <+55>: mov %rbx,-0x20(%rbp)
0x0000000000400733 <+59>: mov $0x0,%eax
0x0000000000400738 <+64>: add $0x18,%rsp
0x000000000040073c <+68>: pop %rbx
0x000000000040073d <+69>: pop %rbp
0x000000000040073e <+70>: retq
End of assembler dump.
(gdb) b *0x0000000000400716
Breakpoint 2 at 0x400716: file abc.cc, line 22.
(gdb) c
Continuing.

Breakpoint 2, 0x0000000000400716 in main () at abc.cc:22
22 Base2 *b2 = new Base2;
(gdb) disas
Dump of assembler code for function main:
0x00000000004006f8 <+0>: push %rbp
0x00000000004006f9 <+1>: mov %rsp,%rbp
0x00000000004006fc <+4>: push %rbx
0x00000000004006fd <+5>: sub $0x18,%rsp
0x0000000000400701 <+9>: mov $0x10,%edi
0x0000000000400706 <+14>: callq 0x400578 <_Znwm@plt>
0x000000000040070b <+19>: mov %rax,%rbx
0x000000000040070e <+22>: mov %rbx,%rdi
0x0000000000400711 <+25>: callq 0x40076a <_ZN5Base2C2Ev>
=> 0x0000000000400716 <+30>: mov %rbx,-0x18(%rbp)
0x000000000040071a <+34>: mov $0x20,%edi
0x000000000040071f <+39>: callq 0x400578 <_Znwm@plt>
0x0000000000400724 <+44>: mov %rax,%rbx
0x0000000000400727 <+47>: mov %rbx,%rdi
0x000000000040072a <+50>: callq 0x40079a <_ZN7DerivedC2Ev>
0x000000000040072f <+55>: mov %rbx,-0x20(%rbp)
0x0000000000400733 <+59>: mov $0x0,%eax
0x0000000000400738 <+64>: add $0x18,%rsp
0x000000000040073c <+68>: pop %rbx
0x000000000040073d <+69>: pop %rbp
0x000000000040073e <+70>: retq
End of assembler dump.

在上述汇编中<+14>处,调用了operator new进行内存分配,然后将地址放于寄存器rax中,在<+25>处调用Base2构造函数,继续分析:

(gdb) p/x $rax
$2 = 0x612c20
(gdb) x/2xg 0x612c20
0x612c20: 0x0000000000400918 0x0000000000000000
(gdb) p &(((Base2*)0)->b)
$3 = (int *) 0x8

首先通过p/x $rax获取b2的地址0x612c20,然后通过x/4xg 0x612c20打印内存地址,地址信息包含存储的属性;接着通过p &(((Base2*)0)->b)来获取变量b的布局,其值为0x8,因此可以说明变量b在类Base2的第八字节处,即vptr之后,那么class base2的结构布局如下:

图片

在上述x/2xg 0x612c20的输出中,有个地址0x0000000000400918,其指向Base2类的虚函数表,这个可以通过如下方式进行验证:

(gdb) p *((Base2*)0x612c20)
$6 = {_vptr.Base2 = 0x400918, b = 0}

但是需要注意的是,其并不是指向虚函数表的首位,而是指向Vtable + 0x10处,下面是类Base2虚函数表的内容:

(gdb) x/4xg 0x0000000000400918-0x10
0x400908 <_ZTV5Base2>: 0x0000000000000000 0x0000000000400980
0x400918 <_ZTV5Base2+16>: 0x000000000040074c 0x0000000000000000
(gdb) x/2i 0x000000000040074c
0x40074c <_ZN5Base22f2Ev>: push %rbp
0x40074d <_ZN5Base22f2Ev+1>: mov %rsp,%rbp

其中,0代表offset,第三项0x400918值与_vptr.Base2一致,其中的内容通过x/2i 0x000000000040074c分析可以看出为Base2::f2()函数地址。那么第二项又代表什么呢?

还记得上篇文章中的RTTI信息么?对!第二项就是指向RTTI信息的地址,可以通过如下命令:

(gdb) x/2xg 0x0000000000400980
0x400980 <_ZTI5Base2>: 0x0000000000600da0 0x0000000000400990
(gdb) x/s 0x0000000000400990
0x400990 <_ZTS5Base2>: "5Base2"

其中,_ZTI5Base2代表typeinfo for Base2,其指向的地址有两个内容,分别是0x0000000000600da0和0x0000000000400990,其中0x400990存储的是类名,可以通过x/s来证明。

然后接着分析0x0000000000600da0存储的内容,如下:

(gdb) x/2xg 0x0000000000600da0
0x600da0 <_ZTVN10__cxxabiv117__class_type_infoE@@CXXABI_1.3+16>: 0x0000003e9628b210 0x0000003e9628b230

_ZTVN10__cxxabiv117__class_type_infoE解析之后为vtable for __cxxabiv1::__class_type_info。

综上,类Base2的内存布局如下图所示:

图片

多重继承

跟上节一样,仍然通过 -fdump-class-hierarchy 参数获取Derived类的详细信息,如下:

Vtable for Derived
Derived::_ZTV7Derived: 7u entries
0 (int (*)(...))0
8 (int (*)(...))(& _ZTI7Derived)
16 (int (*)(...))Base1::f1
24 (int (*)(...))Derived::f2
32 (int (*)(...))-16
40 (int (*)(...))(& _ZTI7Derived)
48 (int (*)(...))Derived::_ZThn16_N7Derived2f2Ev

Class Derived
size=32 align=8
base size=32 base align=8
Derived (0x0x7f2708268af0) 0
vptr=((& Derived::_ZTV7Derived) + 16u)
Base1 (0x0x7f2708127840) 0
primary-for Derived (0x0x7f2708268af0)
Base2 (0x0x7f27081278a0) 16
vptr=((& Derived::_ZTV7Derived) + 48u)

接着继续使用gdb进行分析:

(gdb) disas
Dump of assembler code for function main:
0x00000000004006f8 <+0>: push %rbp
0x00000000004006f9 <+1>: mov %rsp,%rbp
0x00000000004006fc <+4>: push %rbx
0x00000000004006fd <+5>: sub $0x18,%rsp
0x0000000000400701 <+9>: mov $0x10,%edi
0x0000000000400706 <+14>: callq 0x400578 <_Znwm@plt>
0x000000000040070b <+19>: mov %rax,%rbx
0x000000000040070e <+22>: mov %rbx,%rdi
0x0000000000400711 <+25>: callq 0x40076a <_ZN5Base2C2Ev>
0x0000000000400716 <+30>: mov %rbx,-0x18(%rbp)
0x000000000040071a <+34>: mov $0x20,%edi
0x000000000040071f <+39>: callq 0x400578 <_Znwm@plt>
0x0000000000400724 <+44>: mov %rax,%rbx
0x0000000000400727 <+47>: mov %rbx,%rdi
0x000000000040072a <+50>: callq 0x40079a <_ZN7DerivedC2Ev>
=> 0x000000000040072f <+55>: mov %rbx,-0x20(%rbp)
0x0000000000400733 <+59>: mov $0x0,%eax
0x0000000000400738 <+64>: add $0x18,%rsp
0x000000000040073c <+68>: pop %rbx
0x000000000040073d <+69>: pop %rbp
0x000000000040073e <+70>: retq
End of assembler dump.
(gdb) p/x $rax
$8 = 0x612c40
(gdb) p sizeof(Derived)
$9 = 32
(gdb) x/6xg 0x612c40
0x612c40: 0x00000000004008e0 0x0000000000000000
0x612c50: 0x0000000000400900 0x0000000000000000
0x612c60: 0x0000000000000000 0x00000000000203a1
(gdb) p &(((Derived*)0)->a)
$15 = (int *) 0x8
(gdb) p &(((Derived*)0)->b)
$16 = (int *) 0x18
(gdb) p &(((Derived*)0)->c)
$17 = (int *) 0x1c
p *((Derived*)0x612c40)
$13 = {<Base1> = {_vptr.Base1 = 0x4008e0, a = 0}, <Base2> = {_vptr.Base2 = 0x400900, b = 0}, c = 0}

从上述代码可以看出,Derived的结构布局如下:

图片

接着,我们分析类Derived的虚函数表:

(gdb) x/7xg 0x00000000004008e0 - 0x10
0x4008d0 <_ZTV7Derived>: 0x0000000000000000 0x0000000000400938
0x4008e0 <_ZTV7Derived+16>: 0x0000000000400740 0x0000000000400758
0x4008f0 <_ZTV7Derived+32>: 0xfffffffffffffff0 0x0000000000400938
0x400900 <_ZTV7Derived+48>: 0x0000000000400763

其对应如下:

Vtable for Derived
Derived::_ZTV7Derived: 7u entries
0 (int (*)(...))0
8 (int (*)(...))(& _ZTI7Derived)
16 (int (*)(...))Base1::f1
24 (int (*)(...))Derived::f2
32 (int (*)(...))-16
40 (int (*)(...))(& _ZTI7Derived)
48 (int (*)(...))Derived::_ZThn16_N7Derived2f2Ev

为了验证如上,继续使用gdb进行操作:

(gdb) x/2xg 0x0000000000400938
0x400938 <_ZTI7Derived>: 0x0000000000600df8 0x0000000000400970
(gdb) x/4xi 0x0000000000400740
0x400740 <_ZN5Base12f1Ev>: push %rbp
0x400741 <_ZN5Base12f1Ev+1>: mov %rsp,%rbp
0x400744 <_ZN5Base12f1Ev+4>: mov %rdi,-0x8(%rbp)
0x400748 <_ZN5Base12f1Ev+8>: nop
(gdb) x/2xi 0x0000000000400740
0x400740 <_ZN5Base12f1Ev>: push %rbp
0x400741 <_ZN5Base12f1Ev+1>: mov %rsp,%rbp
(gdb) x/2xi 0x0000000000400758
0x400758 <_ZN7Derived2f2Ev>: push %rbp
0x400759 <_ZN7Derived2f2Ev+1>: mov %rsp,%rbp
(gdb) x/4xi 0x0000000000400763
0x400763 <_ZThn16_N7Derived2f2Ev>: sub $0x10,%rdi
0x400767 <_ZThn16_N7Derived2f2Ev+4>: jmp 0x400758 <_ZN7Derived2f2Ev>
0x400769: nop
0x40076a <_ZN5Base2C2Ev>: push %rbp

在上面的内存布局中,_ZThn16_N7Derived2f2Ev在上篇文章中没有进行分析,那么这个标记代表什么意思么,其作用又是什么呢?

通过c++filt将其demanged之后,non-virtual thunk to Derived::f2()。那么这个thunk的目的或者意义在哪呢?

我们看下如下代码:

Derived *d = new Derived;
Base1 *b1 = (Base1*)d;
Base2 *b2 = (Base2*)d;

std::cout << d << " " << b1 << " " << b2 << std::endl;

((Base2*)d)->f2();

输出如下:

0x1cc0c20 0x1cc0c20 0x1cc0c30

可以看出,同样是一个地址,使用Base1转换的地址和使用Base2转换的地址不同,这是因为在转换的时候,对指针进行了偏移,即加上了sizeof(Base1)。

好了,言归正传。

分析下如下情况:

Base1* b1 = new Derived();
b1->f1();

其正常工作,不需要移动任何指针,这是因为b1指向Derived对象的首地址。

那么如下是下面这种情况呢?

Base2* b2 = new Derived();
// 相当于 Derived *d = new Derived;
// Base2* b2 = d + sizeof(Base1);
b2->f2();

对于创建对象操作,在上述代码中有大致解释,那么对于b2->f2()操作,编译器又是如何实现的呢?

其必须将b2所指向的指针调整为具体的Derived对象的其实指针,这样才能正确的调用f2。此操作可以在运行时完成,即在运行时候通过调整指针指向进行操作,但这样效率明显不高。所以为了解决效率问题,编译器引入了thunk,即在编译阶段进行生成。那么针对上面的b2->f2()操作,编译器会进行如下:

void thunk_to_Derived_f2(Base2* this) {
this -= sizeof(Base1);
Derived::f2(this);
}

我们仍然通过gdb来验证这一点,如下:

(gdb) x/2i 0x0000000000400763
0x400763 <_ZThn16_N7Derived2f2Ev>: sub $0x10,%rdi
0x400767 <_ZThn16_N7Derived2f2Ev+4>: jmp 0x400758 <_ZN7Derived2f2Ev>

其中,寄存器rdi中存储的是this指针,对this指针进行-16操作,然后进行调用 Derived::f2(this) 。

继续分析虚函数表的内容,其第二项为TypeInfo信息:

(gdb) x/2xg 0x0000000000400938
0x400938 <_ZTI7Derived>: 0x0000000000600df8 0x0000000000400970
(gdb) x/2xg 0x0000000000600df8
0x600df8 <_ZTVN10__cxxabiv121__vmi_class_type_infoE@@CXXABI_1.3+16>: 0x0000003e9628df70 0x0000003e9628df90
(gdb) x/s 0x0000000000400970
0x400970 <_ZTS7Derived>: "7Derived"

所以,综合以上内容,class Derived的内存布局如下图所示:

通过上图,可以看出class Derived对象有两个vptr,那么有没有可能将这俩vptr合并成一个呢?

答案是不行。这是因为与单继承不同,在多继承中,class Base1和class Base2相互独立,它们的虚函数没有顺序关系,即f1和f2有着相同对虚表起始位置的偏移量,所以不可以按照偏移量的顺序排布;并且class Base1和class Base2中的成员变量也是无关的,因此基类间也不具有包含关系;这使得class Base1和class Base2在class Derived中必须要处于两个不相交的区域中,同时需要有两个虚指针分别对它们虚函数表索引。

偏移(offset)

在前面的内容中,我们多次提到了top offset,在上节Derived的虚函数表中,有两个top offset,其值分别为0和-16,那么这个offset起什么作用呢?

在此,先给出结论:将对象从当前这个类型转换为该对象的实际类型的地址偏移量。

仍然以前面的class Derived为例,其虚函数表布局如下:

Vtable for Derived
Derived::_ZTV7Derived: 7u entries
0 (int (*)(...))0
8 (int (*)(...))(& _ZTI7Derived)
16 (int (*)(...))Base1::f1
24 (int (*)(...))Derived::f2
32 (int (*)(...))-16
40 (int (*)(...))(& _ZTI7Derived)
48 (int (*)(...))Derived::_ZThn16_N7Derived2f2Ev

为了能方便理解本节内容,我们不妨将Derived虚函数表认为是 class Base1和class Base2两个类的虚函数表拼接而成 。因为是多重继承,所以编译器将先继承的那个认为是 主基类(primary base) ,因此Derived类的主基类就是class Base1。

在多继承中,当最左边的类中没有虚函数时候,编译器会将第一个有虚函数的基类移到对象的开头,这样对象的开头总是有vptr。

首先看虚函数表的前半部分,如下:

0     (int (*)(...))0
8 (int (*)(...))(& _ZTI7Derived)
16 (int (*)(...))Base1::f1
24 (int (*)(...))Derived::f2

正是因为编译器将class Base1作为Derived的主基类,并将自己的函数加入其中。从上述可以看出offset为0,也就是说Base1类的指针不需要偏移就可以直接访问Derived::f2()。

接着看虚函数表的下半部分:

32    (int (*)(...))-16
40 (int (*)(...))(& _ZTI7Derived)
48 (int (*)(...))Derived::_ZThn16_N7Derived2f2Ev

偏移值为-16,因为是多重继承,所以class Base1和class Base2类型的指针或者引用都可以指向class Derived对象,那么又是如何调用正确的成员函数呢?

Base2* b2 = new Derived;
b2->f2(); //最终调用Derived::f2();

由于不同的基类起点可能处于不同的位置,因此当需要将它们转化为实际类型时,this指针的偏移量也不相同,且由于多态的特性,b2的实际类型在编译时期是无法确定的;那必然需要一个东西帮助我们在运行时期确定b2的实际类型,这个东西就是offset_to_top​。通过让this指针加上offset_to_top的偏移量,就可以让this指针指向实际类型的起始地址。

结语

写这块的时候,感觉需要写的还是很多的,也有很多内容没写,比如虚拟继承、菱形继承的布局都在本文中没有体现,后面有机会再接着分析。

今天的文章就到这,我们下期见!

责任编辑:武晓燕 来源: 高性能架构探索
相关推荐

2024-02-02 09:00:14

内存泄漏对象

2023-05-29 07:43:32

JVM内存调优

2024-01-02 12:05:26

Java并发编程

2023-08-01 12:51:18

WebGPT机器学习模型

2024-01-19 08:25:38

死锁Java通信

2024-02-04 00:00:00

Effect数据组件

2023-01-10 08:43:15

定义DDD架构

2023-07-26 13:11:21

ChatGPT平台工具

2024-11-13 11:12:08

JVM内存区域

2023-10-06 14:49:21

SentinelHystrixtimeout

2024-02-02 11:03:11

React数据Ref

2023-05-05 06:54:07

MySQL数据查询

2022-06-16 07:50:35

数据结构链表

2023-03-26 22:31:29

2023-08-26 21:34:28

Spring源码自定义

2024-03-06 08:28:16

设计模式Java

2022-12-06 07:53:33

MySQL索引B+树

2023-07-30 22:29:51

BDDMockitoAssert测试

2023-06-26 13:08:52

GraphQL服务数据

2022-07-13 08:16:49

RocketMQRPC日志
点赞
收藏

51CTO技术栈公众号