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兼容。
详见之前文章:MSVC版本的二进制兼容性
二、与 ABI 有关的知识
在理解哪些行为是否会破坏 ABI 兼容性之前,我们需要预先了解一些C++基础知识。
2.1 类如何访问成员变量
在 C++ 中,struct 和 class 是通过偏移量来访问成员变量的,如果改变了成员变量的顺序,偏移量也会相应改变。
2.2 虚函数表
虚函数是通过虚函数表来管理和访问的,改变虚函数顺序、新增/删除虚函数都会改变虚函数表,可以参考之前有关虚函数的文章:深入理解C++虚函数
2.3 Name Mangling
C++ 编译器会把函数的名字、参数等信息(或者叫函数签名)编码成一个唯一的字符串,用作链接符号,这样就能在编译期完成检查,从而避免运行时报错,这种行为称作Name Mangling
,例如:
1 | namespace wikipedia |
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字节,所以会出问题。
但是,如果动态库提供了创建对象的方法,始终在动态库内部创建对象,则没有该问题,如:
1 | class EXPORT_API Koi { |
也可以通过Impl设计模式来解决该问题。
1 | class EXPORT_API Koi { |
1 | // 动态库内部 |
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。函数参数的传递方式有多种,如压栈方式、寄存器方式。如果选择压栈方式,在维持栈平衡上有分调用者维持、函数自身维持,在参数的传递顺序也有多种,从左到右,还是从右到左。
具体介绍可以参考之前的文章:从汇编的角度分析函数调用过程
3.7 添加虚函数
添加虚函数会导致虚函数表发生了变化,即便是在最尾端添加虚函数也可能不行,因为当前类可能已经被其他类继承了。
3.8 不同系统的动态库
不同操作系统所支持的动态库的二进制格式不一样,因此不同系统的动态库肯定是无法兼容的。
四、不破坏ABI兼容性的行为
下面的操作不会破坏 ABI 兼容性:
- 添加新的类
- 修改成员变量的名称
- 更改非虚成员函数的顺序
五、Windows COM 实现 ABI 兼容的方式
很多时候,由于功能更新,对接口的修改不可避免的,既然接口已经发生大改动,那显然很难满足ABI兼容性,此时可以通过版本管理的方式来保证 ABI 兼容性,如:
1 | // 版本1 |
1 | // 版本2 |
上面方式也是 COM 实现 ABI 兼容性的方式,需要在动态库中仍要保留老的接口和实现,以实现向前兼容,这种方式有个弊端就是会存在很多版本的接口,如:
1 | IDirect3D7, IDirect3D8, IDirect3D9, ID3D10*, ID3D11* |
本文参考了: