简介：工作中使用LLDB调试器调试这一段C++多继承程序的时候，发现通过lldb print(expression命令的别名) 命令获取的指针地址和实际理解的C++的内存模型的地址不一样。那么到底是什么原因呢？
作者 | 扬阜 来源 | 阿里技术公众号
一 问题背景1 实践验证
工作中使用LLDB调试器调试这一段C++多继承程序的时候，发现通过lldb print(expression命令的别名) 命令获取的指针地址和实际理解的C++的内存模型的地址不一样。那么到底是什么原因呢？程序如下：
class Base {
public:
Base(){}
protected:
float x;
};
class VBase {
public:
VBase(){}
virtual void test(){};
virtual void foo(){};
protected:
float x;
};
class VBaseA: public VBase {
public:
VBaseA(){}
virtual void test(){}
virtual void foo(){};
protected:
float x;
};
class VBaseB: public VBase {
public:
VBaseB(){}
virtual void test(){
printf("test \n");
}
virtual void foo(){};
protected:
float x;
};
class VDerived : public VBaseA, public Base, public VBaseB {
public:
VDerived(){}
virtual void test(){}
virtual void foo(){};
protected:
float x;
};
int main(int argc, char *argv[])
{
VDerived *pDerived = new VDerived(); //0x0000000103407f30
Base *pBase = (Base*)pDerived; //0x0000000103407f40
VBaseA *pvBaseA = static_cast< VBaseA*>(pDerived);//0x0000000103407f30
VBaseB *pvBaseB = static_cast< VBaseB*>(pDerived);//0x0000000103407f30 这里应该为0x0000000103407f48,但是显示的是0x0000000103407f30
unsigned long pBaseAddressbase = (unsigned long)pBase;
unsigned long pvBaseAAddressbase = (unsigned long)pvBaseA;
unsigned long pvBaseBAddressbase = (unsigned long)pvBaseB;
pvBaseB->test();
}通过lldb print命令获取的地址如下图：
正常理解的C++内存模型
由于我使用的是x86_64的mac系统，所以指针是8字节对齐,align=8。
按正常的理解的C++内存模型：pDerived转换为Base 类型pBase,地址偏移了16，是没问题的。
pDerived转化为VBaseA，由于共用了首地址为0x0000000103407f30，一样可以理解。pDerived转化为Base，地址偏移了16个字节(sizeof(VBaseA))为0x0000000103407f40,也是符合预期的。
但是pDerived转化为VBase 类型pBaseB内存地址应该偏移24，为0x0000000103407f48；而不是0x0000000103407f30(对象的首地址)，这个到底是什么原因引起的的呢？
2 验证引发的猜测
对于上面的这段代码
Base 类中没有虚函数，VBaseB 中有虚函数test和foo，猜测如下
1.不含有虚函数的(不含有虚表的)基类的指针，在类型转换时编译器对地址按照实际偏移。
2.含有虚函数的(含有虚表的)基类指针，在类型转换时，编译器实际上没有做地址的偏移，还是指向派生类，并没有指向实际的VBaseB类型。
二 现象带来的问题1.有虚函数的(含有虚表的)基类指针，在派生类类型转换为有虚函数的基类时，编译器背后有做真实的地址偏移吗？
2.如果做了偏移
- 那C++中在通过基类指针调用派生类重写的虚函数以及通过派生类指针调用虚函数的时候，编译器是如何保证这两种调用this指针的值是一样的，以确保调用的正确性的？
- 那为什么LLDB expression获取的地址是派生类对象的首地址呢？
3.如果没有做偏移，那是如何通过派生类的指针调用基类成员变量和函数的？
三 现象核心原因- 编译器背后和普通的非虚函数继承一样，也做了指针的偏移。
- 做了指针偏移，C++ 中基类对象指针调用派生类对象时,编译器通过thunk技术来实现每次参数调用和参数返回this地址的调整。
- LLDB expression显示的是派生类对象的首地址(0x0000000103407f30),而不是偏移后基类对象的首地址(0x0000000103407f48),是由于LLDB调试器在expression向用户展示的时候,对于虚函数继承的基类指针LLDB内部会通过summary format来对要获取的结果进行格式化。summary format时，会根据当前的内存地址获取C++运行时的动态类型和地址，来向用户展示。
1 指针类型转换时编译器是否做了偏移？
汇编指令分析
有虚函数的(含有虚表的)基类指针，在派生类类型转换为有虚函数的基类时,编译器背后有做真实的地址偏移吗？
基于上面的猜测，通过下面运行时反汇编的程序，来验证上面的猜测：
在开始反汇编程序之前，有一些下面要用到的汇编知识的普及。如果熟悉，可以忽略跳过。
注意：由于小编使用的是mac操作系统，所以处理器使用的是AT&T语法；和Intel语法不一样。
AT&T语法的指令是从左到右，第一个是源操作数，第二个是目的操作数，比如：
movl %esp, %ebp //movl是指令名称。%则表明esp和ebp是寄存器.在AT&T语法中, 第一个是源操作数,第二个是目的操作数。而Intel指令是从右到左，第二个是源操作数，第一个是目的操作数
MOVQ EBP, ESP //interl手册，你会看到是没有%的intel语法, 它的操作数顺序刚好相反在x86_64的寄存器调用约定规定中
1.第一个参数基本上放在：RDI/edi寄存器,第二个参数：RSI/esi寄存器，第三个参数：RDX寄存器,第四个参数：RCD寄存器,第五个参数：R8寄存器,第六个参数：R9 寄存器；
2.如果超过六个参数在函数里就会通过栈来访问额外的参数；
3.函数返回值一般放在eax寄存器，或者rax寄存器。
下面使用的mac Unix操作系统，本文用到的汇编指令都是AT&T语法，在函数传参数时的第一个参数都放在RDI寄存器中。
下面是上面的main程序从开始执行到退出程序的所有汇编程序
通过上看的汇编代码我们发现编译器在做类型转换的时候不管是继承的基类有虚函数，还是没有虚函数，编译器都会做实际的指针偏移，偏移到实际的基类对象的地址，证明上面的猜测是错误的。编译器在类型转换的时候不区分有没有虚函数，都是实际做了偏移的。
内存分析
上面的猜测，后来我通过LLDB调试器提供的：memory read ptr（memory read 命令缩写 x ）得到了验证
(lldb) memory read pDerived
0x103407f30: 40 40 00 00 01 00 00 00 00 00 00 00 00 00 00 00 @@..............
0x103407f40: 10 00 00 00 00 00 00 00 60 40 00 00 01 00 00 00 ........`@......
(lldb) memory read pvBaseB
0x103407f48: 60 40 00 00 01 00 00 00 00 00 00 00 00 00 00 00 `@..............
0x103407f58: de 2d 05 10 00 00 00 00 00 00 00 00 00 00 00 00 .-..............我们发现不同类型的指针 在内存中确实读取到的内容分别是pDerived:0x103407f30 pvBaseB:0x103407f48内存地址都不一样；都是实际偏移后地址。
2 虚函数调用如何保证this的值一致的呢？
那既然内容中的真实地址是偏移后的，派生类重写了基类的虚函数，在通过基类指针调用派生类重新的虚函数的时候和通过派生类调用自身实现的虚函数的时候，编译器是如何保证这两种调用this指针的值是一样的，来确保调用的正确性的？
在网上查阅资料得知：C++在调用函数的时候， 编译器通过thunk技术对this指针的内容做了调整，使其指向正确的内存地址。那么什么是thunk技术？编译器是如何实现的呢？
虚函数调用汇编指令分析
通过上面main函数不难发现的pvBaseB->test() 的反汇编：
pBaseB->test();
0x100003c84 < +244>: movq -0x40(%rbp), %rax //-x40存方的是pBaseB指针的内容，这里取出pBaseB指向的地址
0x100003c88 < +248>: movq (%rax), %rcx //然后将 rax的内容赋值给rcx
0x100003c8b < +251>: movq %rax, %rdi // 之后再将rax的值给到rdi寄存器：我们都知道，rdi寄存器是函数调用的第一个参数，这里的this是基类的地址
-> 0x100003c8e < +254>: callq *(%rcx) // 在这里取出rcx的地址，然后通过*(rcx) 间接调用rcx中存的地址我们再跳到VDerived::test函数的汇编实现, 在这里通过lldb的命令：register read rdi 查看函数的第一个传参，也就是 this的地址，已经是派生类的地址了，不是调用前基类的地址
testCPPVirtualMemeory`VDerived::test:
0x100003e00 < +0>: pushq %rbp // 栈低指针压栈
0x100003e01 < +1>: movq %rsp, %rbp // 将BP指针指向SP，因为上一级函数的栈顶指针是下一级函数的栈底指针
0x100003e04 < +4>: subq $0x10, %rsp // 开始函数栈帧空间
0x100003e08 < +8>: movq %rdi, -0x8(%rbp) // 将函数第一个参数入栈，也就是this 指针
-> 0x100003e0c < +12>: leaq 0x15c(%rip), %rdi ; "test\n"
0x100003e13 < +19>: movb $0x0, %al
0x100003e15 < +21>: callq 0x100003efc ; symbol stub for: printf
0x100003e1a < +26>: addq $0x10, %rsp //回收栈空间
0x100003e1e < +30>: popq %rbp //出栈 指回上一层 rbp
0x100003e1f < +31>: retq //指向下一条命令
通过上面的汇编我们分析，编译器在调用虚函数表中的函数时，是通过 *(%rcx) 间接寻址，然后中间做了某一个操作，跳到 test的实现，那么这个过程中thunk做了什么操作呢？
llvm-thunk源代码分析
小编使用的IDE都使用的是LLVM编译器，于是通过翻看LLVM的源码找到了答案: 在VTableBuilder.cpp的AddMethods函数，小编找到了答案，描述如下：
// Now go through all virtual member functions and add them to the current
// vftable. This is done by
// - replacing overridden methods in their existing slots, as long as they
// don't require return adjustment; calculating This adjustment if needed.
// - adding new slots for methods of the current base not present in any
// sub-bases;
// - adding new slots for methods that require Return adjustment.
// We keep track of the methods visited in the sub-bases in MethodInfoMap.编译器在编译的时候会判断基类的虚函数派生类有没有覆盖，如果有实现的时候，则动态替换虚函数表中的地址为派生类的地址，同时：
1.会计算调用时this指针的地址是否需要调整，如果需要调整的话，会为当前的方法开辟一块新的内存空间；
2.也会为需要this返回值的函数开辟一块新的内存空间；
代码如下：
void VFTableBuilder::AddMethods(BaseSubobject Base, unsigned BaseDepth,
const CXXRecordDecl *LastVBase,
BasesSetVectorTy &VisitedBases) {
const CXXRecordDecl *RD = Base.getBase();
if (!RD->isPolymorphic())
return;
const ASTRecordLayout &Layout = Context.getASTRecordLayout(RD);
// See if this class expands a vftable of the base we look at, which is either
// the one defined by the vfptr base path or the primary base of the current
// class.
const CXXRecordDecl *NextBase = nullptr, *NextLastVBase = LastVBase;
CharUnits NextBaseOffset;
if (BaseDepth < WhichVFPtr.PathToIntroducingObject.size()) {
NextBase = WhichVFPtr.PathToIntroducingObject[BaseDepth];
if (isDirectVBase(NextBase, RD)) {
NextLastVBase = NextBase;
NextBaseOffset = MostDerivedClassLayout.getVBaseClassOffset(NextBase);
} else {
NextBaseOffset =
Base.getBaseOffset() + Layout.getBaseClassOffset(NextBase);
}
} else if (const CXXRecordDecl *PrimaryBase = Layout.getPrimaryBase()) {
assert(!Layout.isPrimaryBaseVirtual() &&
"No primary virtual bases in this ABI");
NextBase = PrimaryBase;
NextBaseOffset = Base.getBaseOffset();
}
if (NextBase) {
AddMethods(BaseSubobject(NextBase, NextBaseOffset), BaseDepth + 1,
NextLastVBase, VisitedBases);
if (!VisitedBases.insert(NextBase))
llvm_unreachable("Found a duplicate primary base!");
}
SmallVector< const CXXMethodDecl*, 10> VirtualMethods;
// Put virtual methods in the proper order.
GroupNewVirtualOverloads(RD, VirtualMethods);
// Now go through all virtual member functions and add them to the current
// vftable. This is done by
// - replacing overridden methods in their existing slots, as long as they
// don't require return adjustment; calculating This adjustment if needed.
// - adding new slots for methods of the current base not present in any
// sub-bases;
// - adding new slots for methods that require Return adjustment.
// We keep track of the methods visited in the sub-bases in MethodInfoMap.
for (const CXXMethodDecl *MD : VirtualMethods) {
FinalOverriders::OverriderInfo FinalOverrider =
Overriders.getOverrider(MD, Base.getBaseOffset());
const CXXMethodDecl *FinalOverriderMD = FinalOverrider.Method;
const CXXMethodDecl *OverriddenMD =
FindNearestOverriddenMethod(MD, VisitedBases);
ThisAdjustment ThisAdjustmentOffset;
bool ReturnAdjustingThunk = false, ForceReturnAdjustmentMangling = false;
CharUnits ThisOffset = ComputeThisOffset(FinalOverrider);
ThisAdjustmentOffset.NonVirtual =
(ThisOffset - WhichVFPtr.FullOffsetInMDC).getQuantity();
if ((OverriddenMD || FinalOverriderMD != MD) &&
WhichVFPtr.getVBaseWithVPtr())
CalculateVtordispAdjustment(FinalOverrider, ThisOffset,
ThisAdjustmentOffset);
unsigned VBIndex =
LastVBase ? VTables.getVBTableIndex(MostDerivedClass, LastVBase) : 0;
if (OverriddenMD) {
// If MD overrides anything in this vftable, we need to update the
// entries.
MethodInfoMapTy::iterator OverriddenMDIterator =
MethodInfoMap.find(OverriddenMD);
// If the overridden method went to a different vftable, skip it.
if (OverriddenMDIterator == MethodInfoMap.end())
continue;
MethodInfo &OverriddenMethodInfo = OverriddenMDIterator->second;
VBIndex = OverriddenMethodInfo.VBTableIndex;
// Let's check if the overrider requires any return adjustments.
// We must create a new slot if the MD's return type is not trivially
// convertible to the OverriddenMD's one.
// Once a chain of method overrides adds a return adjusting vftable slot,
// all subsequent overrides will also use an extra method slot.
ReturnAdjustingThunk = !ComputeReturnAdjustmentBaseOffset(
Context, MD, OverriddenMD).isEmpty() ||
OverriddenMethodInfo.UsesExtraSlot;
if (!ReturnAdjustingThunk) {
// No return adjustment needed - just replace the overridden method info
// with the current info.
MethodInfo MI(VBIndex, OverriddenMethodInfo.VFTableIndex);
MethodInfoMap.erase(OverriddenMDIterator);
assert(!MethodInfoMap.count(MD) &&
"Should not have method info for this method yet!");
MethodInfoMap.insert(std::make_pair(MD, MI));
continue;
}
// In case we need a return adjustment, we'll add a new slot for
// the overrider. Mark the overridden method as shadowed by the new slot.
OverriddenMethodInfo.Shadowed = true;
// Force a special name mangling for a return-adjusting thunk
// unless the method is the final overrider without this adjustment.
ForceReturnAdjustmentMangling =
!(MD == FinalOverriderMD && ThisAdjustmentOffset.isEmpty());
} else if (Base.getBaseOffset() != WhichVFPtr.FullOffsetInMDC ||
MD->size_overridden_methods()) {
// Skip methods that don't belong to the vftable of the current class,
// e.g. each method that wasn't seen in any of the visited sub-bases
// but overrides multiple methods of other sub-bases.
continue;
}
// If we got here, MD is a method not seen in any of the sub-bases or
// it requires return adjustment. Insert the method info for this method.
MethodInfo MI(VBIndex,
HasRTTIComponent ? Components.size() - 1 : Components.size(),
ReturnAdjustingThunk);
assert(!MethodInfoMap.count(MD) &&
"Should not have method info for this method yet!");
MethodInfoMap.insert(std::make_pair(MD, MI));
// Check if this overrider needs a return adjustment.
// We don't want to do this for pure virtual member functions.
BaseOffset ReturnAdjustmentOffset;
ReturnAdjustment ReturnAdjustment;
if (!FinalOverriderMD->isPure()) {
ReturnAdjustmentOffset =
ComputeReturnAdjustmentBaseOffset(Context, FinalOverriderMD, MD);
}
if (!ReturnAdjustmentOffset.isEmpty()) {
ForceReturnAdjustmentMangling = true;
ReturnAdjustment.NonVirtual =
ReturnAdjustmentOffset.NonVirtualOffset.getQuantity();
if (ReturnAdjustmentOffset.VirtualBase) {
const ASTRecordLayout &DerivedLayout =
Context.getASTRecordLayout(ReturnAdjustmentOffset.DerivedClass);
ReturnAdjustment.Virtual.Microsoft.VBPtrOffset =
DerivedLayout.getVBPtrOffset().getQuantity();
ReturnAdjustment.Virtual.Microsoft.VBIndex =
VTables.getVBTableIndex(ReturnAdjustmentOffset.DerivedClass,
ReturnAdjustmentOffset.VirtualBase);
}
}
AddMethod(FinalOverriderMD,
ThunkInfo(ThisAdjustmentOffset, ReturnAdjustment,
ForceReturnAdjustmentMangling ? MD : nullptr));
}
}通过上面代码分析，在this 需要调整的时候，都是通过AddMethod(FinalOverriderMD，ThunkInfo(ThisAdjustmentOffset, ReturnAdjustment，ForceReturnAdjustmentMangling ? MD : nullptr))函数来添加一个ThunkInfo的结构体，ThunkInfo在结构体(实现在ABI.h)如下：
struct ThunkInfo {
/// The \c this pointer adjustment.
ThisAdjustment This;
/// The return adjustment.
ReturnAdjustment Return;
/// Holds a pointer to the overridden method this thunk is for,
/// if needed by the ABI to distinguish different thunks with equal
/// adjustments. Otherwise, null.
/// CAUTION: In the unlikely event you need to sort ThunkInfos, consider using
/// an ABI-specific comparator.
const CXXMethodDecl *Method;
ThunkInfo() : Method(nullptr) { }
ThunkInfo(const ThisAdjustment &This, const ReturnAdjustment &Return,
const CXXMethodDecl *Method = nullptr)
: This(This), Return(Return), Method(Method) {}
friend bool operator==(const ThunkInfo &LHS, const ThunkInfo &RHS) {
return LHS.This == RHS.This && LHS.Return == RHS.Return &&
LHS.Method == RHS.Method;
}
bool isEmpty() const {
return This.isEmpty() && Return.isEmpty() && Method == nullptr;
}
};
}Thunkinfo的结构体有一个method,存放函数的真正实现，This和Return记录this需要调整的信息，然后在生成方法的时候，根据这些信息，编译器自动插入thunk函数的信息，通过ItaniumMangleContextImpl::mangleThunk(const CXXMethodDecl *MD,const ThunkInfo &Thunk,raw_ostream &Out)的函数，我们得到了证实，函数如下：
（mangle和demangle：将C++源程序标识符(original C++ source identifier)转换成C++ ABI标识符(C++ ABI identifier)的过程称为mangle；相反的过程称为demangle。wiki）
void ItaniumMangleContextImpl::mangleThunk(const CXXMethodDecl *MD,
const ThunkInfo &Thunk,
raw_ostream &Out) {
// < special-name> ::= T < call-offset> < base encoding>
// # base is the nominal target function of thunk
// < special-name> ::= Tc < call-offset> < call-offset> < base encoding>
// # base is the nominal target function of thunk
// # first call-offset is 'this' adjustment
// # second call-offset is result adjustment
assert(!isa< CXXDestructorDecl>(MD) &&
"Use mangleCXXDtor for destructor decls!");
CXXNameMangler Mangler(*this, Out);
Mangler.getStream() GetForwardCompilerType())) {
// The dynamic type we found was the same type,
// so we don't have a dynamic type here...
return false;
}
// The offset_to_top is two pointers above the vtable pointer.
const uint32_t addr_byte_size = process->GetAddressByteSize();
const lldb::addr_t offset_to_top_location =
vtable_address_point - 2 * addr_byte_size;
// Watch for underflow, offset_to_top_location should be less than
// vtable_address_point
if (offset_to_top_location >= vtable_address_point)
return false;
const int64_t offset_to_top = process->ReadSignedIntegerFromMemory(
offset_to_top_location, addr_byte_size, INT64_MIN, error);
if (offset_to_top == INT64_MIN)
return false;
// So the dynamic type is a value that starts at offset_to_top
// above the original address.
lldb::addr_t dynamic_addr = original_ptr + offset_to_top;
if (!process->GetTarget().GetSectionLoadList().ResolveLoadAddress(
dynamic_addr, dynamic_address)) {
dynamic_address.SetRawAddress(dynamic_addr);
}
return true;
}
}
}
return class_type_or_name.IsEmpty() == false;
}通过上面代码分析可知，每次在通过LLDB 命令expression动态调用 指针地址的时候，LLDB 会去按照调试器默认的格式进行格式化，格式化的前提是动态获取到对应的类型和偏移后的地址；在碰到C++有虚表的时候，且不是虚表中的第一个基类指针的时候，就会使用指针上头的offset_to_top 获取到这个对应动态的类型和返回动态获取的该类型对象开始的地址。
五 总结
- 上面主要验证了在指针类型转换的时候,编译器内部做了真实的地址偏移；
- 通过上面的分析，我们得知编译器在函数调用时通过thunk技术动态调整入参this指针和返回值this指针，保证C++调用时this的正确性；
- 在通过LLDB expression获取非虚函数基类指针内容时，LLDB内部通过summary format进行格式化转换，格式化转化时会进行动态类型的获取。
1 获取汇编程序
预处理->汇编
clang++ -E main.cpp -o main.i clang++ -S main.i
objdump
objdump -S -C 可执行程序
反汇编利器: hopper
下载hopper，可执行程序拖入即可
Xcode
Xcode->Debug->Debug WorkFlow->Show disassembly
2 导出C++内存布局
Clang++编译器
clang++ -cc1 -emit-llvm -fdump-record-layouts -fdump-vtable-layouts main.cpp
七 参考文献Dynamic types in LLDBVariable Formatting — The LLDB Debuggerlldb/ItaniumABILanguageRuntime.cpp at bc19e289f759c26e4840aab450443d4a85071139 · llvm-mirror/lldb · GitHubclang: lib/AST/VTableBuilder.cpp Source Fileclang: include/clang/Basic/ABI.h Source File
相关技术：
llvm-virtual-thunk llvm-no-virtual-thunk lldb-summary-format lldb-getdynamictypeandaddress
原文链接
本文为阿里云原创内容，未经允许不得转载。
