ABI、名字修饰（mangling）、符号可见性、二进制兼容

库开发 / Infra / 跨组件集成常碰，面试考你“为什么换个 .so 就崩”“extern C 解决什么”“为什么不能随便加私有成员”。

一、ABI 是什么

Application Binary Interface：编译器/库在二进制层面的约定——函数调用约定（参数放寄存器还是栈）、结构体内存布局（大小/成员偏移/对齐）、虚表布局、异常机制、标准库对象的二进制形态等。 源码兼容 ≠ ABI 兼容：同一份代码换 ABI 相关选项编译，产物相互不通用。

例子：库结构体加一个成员=旧 .so 调用新代码段错位 → 段错误（读错偏移）。所以发布 C++ 库常承诺“不会在次要版本改 ABI”。

二、名字修饰（name mangling）

C++ 因重载要区分同名，链接符号需编码类型签名进名字：如

void f(int)  →  _Z1fi
void f(int,char) → _Z1fic

不同编译器/平台 mangling 约定（Itanium ABI 在 Linux/gcc/clang 通用，Windows MSVC 另一套）→ C++ 二进制天然不跨厂商兼容，是 extern "C" 概念的由来。

nm -C 解码；c++filt demangle。

三、extern "C"：C 链接（见 fundamental 关键词）

	C++ 符号	extern "C" 符号
名字	mangled（含签名）	不修饰（直接用函数名）
可被 C 调用	否	是
能重载	是	否（同名只有一个符号）

• 用于 C++ 调用 C 库（extern "C" { #include <c_lib.h> }）以及导出 C ABI 给别的语言/插件。

四、链接属性 / 符号可见性

• 前端 extern 声明（外部定义）；实现处定义。
• static（文件内函数）或匿名命名空间 namespace {}：internal linkage，本 TU 私有，不出现在全局链接符号 → 防跨 TU 冲突。
• 动态库导出控制：Linux -fvisibility=hidden + __attribute__((visibility("default"))) 显式导出，精简符号表、提速加载、避免符号冲突。

五、二进制兼容注意事项（库作者必知）

1. 不要移除/重排/改类型 public 成员、不改变其偏移顺序（除非拆 API major 版本）。
2. 虚函数：末尾追加新虚函数通常保持兼容；中间插/删会破坏派生 vtable 布局。所以加虚函数倾向于加在声明末尾。
3. struct 大小变化：两边同时升级一致才安全；以版本 socket/握手（Chrome/Eigen 会给 struct 显式 size/version 字段）避免隐式 ABI break。
4. 标准库容器换实现（如 vector 内部三指针布局因库版本改）→ 由链接进同一套 libc++ 保证即可，避免跨 ABI 混链不同 stdlib。

六、抛出/捕获跨 .so 异常

• C++ 异常依赖 ABI（Itanium unwind / MSVC SEH），不同 flag（如 -fno-exceptions）或编译器不匹配的异常跨模块传递危险——同属 ABI 层话题。

七、常见题

1. 为什么“把 private 加在类末尾比加在前面 ABI 安全”？ private 仍占布局偏移，若加在末尾且无虚函数、调用方不构造/访问其成员时多数 ABI 安全；真安全法是视为 API break 重新对齐。（严谨答：即便 private 也会影响 sizeof/实现私有物，发布级做法是加独立字段到最后并同步版本。）
2. extern "C" 和重载为什么冲突？
3. 为什么 C 的 .a 可以直接链进 C++？—— 符号无修饰，头用 extern "C" 包裹即可。
4. 动态升级 .so 要关注什么？—— ABI 兼容性；用 version script/link map 固定导出。

八、一句话记忆

ABI 是“二进制契约”；mangling 让 C++ 重载可链接但也竖起与 C 的墙；库更新要守 ABI（布局/虚表/导出符号），否则老.so 和新代码错位就崩。