理解二进制ABI兼容性

ABI是 Application Binary Interface 的缩写，当我们以二进制形式（非源码形式）发布我们的动态库时，就需要关心ABI兼容（也称二进制兼容）。

对于静态库，更新静态库始终都需要该库的使用方重新编译，因此不存在ABI兼容的说法。

一、什么是ABI兼容

假设我们开发了某个动态库（名为something），以动态库的形式提供：something.h、something.lib、something.dll。

有人使用该动态库开发了程序w（w可以是可执行程序，也可以是库），即程序w链接了动态库something，并将程序w打包交付给终端用户，打包文件包含：w.exe、something.dll。

something库是否具有ABI兼容性决定了在更新something.dll时，是否需要重新编译w.exe？

如果不需要重新编译w.exe，则something库是二进制兼容的，否则就不是的。

Microsoft C++（MSVC）编译器工具集在 Visual Studio 2015 之前未实现ABI兼容，但在 Visual Studio 2015（含）之后实现了ABI兼容。

详见之前文章：{% post_link 编程基础/MSVC版本的二进制兼容性 %}

二、与ABI有关的知识

在理解哪些行为是否会破坏ABI兼容性之前，我们需要预先了解一些C++基础知识。

2.1 类如何访问成员变量

在C++中，struct 和 class 是通过偏移量来访问成员变量的，如果改变了成员变量的顺序，偏移量也会相应改变。

2.2 虚函数表

虚函数是通过虚函数表来管理和访问的，改变虚函数顺序、新增/删除虚函数都会改变虚函数表，可以参考之前有关虚函数的文章：{% post_link CPP/深入理解C-虚函数 %}

2.3 Name Mangling

C++编译器会把函数的名字、参数等信息（或者叫函数签名）编码成一个唯一的字符串，用作链接符号，这样就能在编译期完成检查，从而避免运行时报错，这种行为称作Name Mangling，例如：

namespace wikipedia 
{
   class article {
   public:
      std::string format(void);
   }
}

format 函数经过 Name Mangling 之后变成了：_ZN9wikipedia7article6formatEv

Name Mangling使用的算法是可逆的，http://demangler.com/网站提供了通过新函数名逆向推演出原有函数名的功能。

2.4 类如何访问成员函数

C++编译器在编译成员函数时会根据它所在的命名空间、所属类、以及参数等信息，通过Name Mangling生成一个新的函数名。

类的成员函数最终被编译成与对象无关的全局函数，为了使该全局函数可以访问类的其他成员函数和变量，编译器在编译成员函数时会额外添加一个参数，把当前对象的指针传递进去，通过指针来访问成员变量/成员函数。

2.5 头文件的作用

在C/C++中，动态链接库通常会附带头文件，这个头文件可以理解成动态库的“使用说明书”，库的使用者会按照头文件使用该库，编译器会根据该头文件生成二进制代码，然后在运行的时候通过装载器(loader)把可执行文件和动态库绑到一起。

3. 破坏ABI兼容性的行为

如何判断一个改动是不是二进制兼容，主要看老版的头文件能否与新版本的动态库的实际使用方法兼容。因为新的库必然有新的头文件，但是现有的二进制可执行文件还是按旧的头文件来调用动态库。

总结起来，ABI不兼容主要是因为：

• sizeof(class)大小改变
• 数据成员偏移量发生改变
• 虚函数表发生改变
• Name Mangling名发生改变

下面列举了会破坏ABI兼容性的操作。

3.1 添加或删除非静态成员变量

因为sizeof(class)大小发生改变，如之前占用8个字节，新增一个成员变量后占用12字节，但外部代码new class时仍然只分配了8字节，所以会出问题。

但是，如果动态库提供了创建对象的方法，始终在动态库内部创建对象，则没有该问题，如：

class EXPORT_API Koi {
  public:
  // ....
};

EXPORT_API Koi* GetKoi();

也可以通过Impl设计模式来解决该问题。

class EXPORT_API Koi {
  public:
  // ....
  private:
    class Impl;
    Impl* impl_;
};

// 动态库内部
class Koi::Impl {
  public:
    int a_;
    // ...
}

3.2 改变非静态成员变量的顺序

改变了非静态成员变量的顺序就改变了变量的内存偏移，会导致变量读写出错，因此破坏了ABI兼容性。

这个问题也可通过上面3.1节的方式来解决。

3.3 修改函数的名称

这个导致会Name Mangling名发生改变，因此ABI不兼容。

3.4 添加默认的模板类型参数

如Foo<T> 改为 Foo<T, Alloc=alloc<T> >，这个导致会Name Mangling名发生改变，因此不ABI兼容。

3.5 为函数添加默认参数

现有的动态库使用方（可执行程序或另外一个动态库）是基于老的头文件进行编译的，无法传递该默认参数给新的动态库，因此不ABI兼容。

3.6 修改函数参数传递方式

如__cdecl修改为__stdcall。函数参数的传递方式有多种，如压栈方式、寄存器方式。如果选择压栈方式，在维持栈平衡上有分调用者维持、函数自身维持，在参数的传递顺序也有多种，从左到右，还是从右到左。

具体介绍可以参考之前的文章：{% post_link CPP/从汇编的角度分析函数调用过程 %}

3.7 添加虚函数

添加虚函数会导致虚函数表发生了变化，即便是在最尾端添加虚函数也可能不行，因为当前类可能已经被其他类继承了。

3.8 不同系统的动态库

不同操作系统所支持的动态库的二进制格式不一样，因此不同系统的动态库肯定是无法兼容的。

四、不破坏ABI兼容性的行为

下面的操作不会破坏ABI兼容性：

• 添加新的类
• 修改成员变量的名称
• 更改非虚成员函数的顺序

五、Windows COM实现ABI兼容的方式

很多时候，由于功能更新，对接口的修改不可避免的，既然接口已经发生大改动，那显然很难满足ABI兼容性，此时可以通过版本管理的方式来保证ABI兼容性，如：

// 版本1
class Interface {
public:
  virtual void API sendMessage(const char* message) = 0;
};

Interface* CreateInterface(int version);

// 版本2
class Interface2 {
public:
  virtual void API sendMessage(const char* message, int messageSize) = 0;
};

Interface2* CreateInterface(int version);

上面方式也是COM实现ABI兼容性的方式，需要在动态库中仍要保留老的接口和实现，以实现向前兼容，这种方式有个弊端就是会存在很多版本的接口，如：

IDirect3D7, IDirect3D8, IDirect3D9, ID3D10*, ID3D11*
IXMLDOMDocument, IXMLDOMDocument2, IXMLDOMDocument3

本文参考了：
C++ 工程实践(4)：二进制兼容性