目标文件、链接器与 ABI：二进制边界如何决定程序命运

编译通过不等于程序已经成立。 编译器只把单个翻译单元变成目标文件。 链接器才负责把多个目标文件、静态库、动态库、启动代码和运行时拼成可执行产物。 ABI 则规定不同二进制片段如何互相调用、传参、布局对象和处理异常。 很多 C/C++ 难题，本质上不是语法问题，而是二进制契约问题。

目标文件是半成品

目标文件通常包含代码段、只读数据、可写数据、符号表和重定位记录。 它还不是可执行程序。 里面可能引用了尚未确定地址的函数和对象。 链接器会把这些引用解析到最终地址。

render.o
├── .text          机器指令
├── .rodata        字符串常量、只读表
├── .data          已初始化全局对象
├── .bss           零初始化全局对象
├── .symtab        符号表
└── .rela.text     重定位记录

把目标文件看成“带孔的零件”更贴切。 编译器加工零件。 链接器填上孔位，把零件装成机器。

符号是链接器的语言

函数名和全局变量名在目标文件里会变成符号。 C 符号通常接近源码名字。 C++ 符号需要携带命名空间、类、参数类型等信息，因此会 name mangling。

extern "C" int add(int a, int b);

namespace math {
int add(int a, int b);
}

第一行要求 C 链接名，常用于跨语言 ABI。 第二个函数是 C++ 函数，符号名会被编码。 这不是装饰，而是重载和命名空间进入二进制世界的方式。

nm libmath.a
nm -C libmath.a

-C 会 demangle C++ 符号。 排查链接问题时，必须同时看原始符号和 demangle 后的符号。

声明和定义必须在二进制层面一致

头文件声明只是给编译器看的。 链接器看到的是符号。 如果两个翻译单元对同一个函数的声明不一致，编译可能通过，但运行时会破坏调用约定。

// a.c
int decode(const char* p, int len);

// b.c
long decode(const char* p, long len) {
  return len;
}

这种错误在 C 里尤其危险。 调用者和被调用者可能对返回寄存器、参数宽度和栈清理有不同理解。 症状可能是返回值错误、栈破坏或崩溃。

工程上要让公共声明有单一来源。 不要手写重复声明。 跨库接口要有 ABI 测试和符号审计。

静态库只是目标文件归档

.a 或 .lib 静态库不是特殊魔法。 它通常是一组目标文件的归档。 链接器按需从归档中抽取目标文件。 这会造成链接顺序问题。

ar t libcodec.a
c++ main.o -lcodec -lbase
c++ main.o -lbase -lcodec

在某些链接器策略下，库的顺序会影响符号解析。 如果 libcodec 依赖 libbase，顺序写错可能出现 undefined reference。 现代构建系统会隐藏一部分细节，但不能消灭二进制依赖关系。

动态库引入加载期契约

动态库把一部分符号解析推迟到加载期或运行期。 这带来复用和升级能力，也引入版本、搜索路径、符号可见性和初始化顺序风险。

可执行文件
  -> 记录 NEEDED: libengine.so
运行时加载器
  -> 搜索路径
  -> 加载 libengine.so
  -> 解析 PLT/GOT
  -> 执行初始化函数

动态库问题常见在部署环境：

• 本地链接的是新库，线上加载的是旧库。
• LD_LIBRARY_PATH 覆盖了预期路径。
• 符号被意外导出，和另一个库冲突。
• 初始化函数顺序依赖不可控。
• 插件卸载后仍持有函数指针。

这些都是观测和回滚问题，不是单纯代码风格问题。

ABI 规定二进制如何互相理解

API 是源码接口。 ABI 是二进制接口。 ABI 包括调用约定、对象布局、对齐、异常处理、虚表布局、name mangling、标准库类型布局等。

ABI 最容易被忽略的地方是 C++ 类。 即使 private 字段不被调用方直接访问，它也会改变对象大小和成员偏移。 调用方如果按旧头文件编译，运行时就会读写错误位置。

C 接口常被用作稳定 ABI 外壳

C ABI 更简单。 它没有重载、模板、异常、隐式构造析构和复杂对象布局。 因此很多插件系统、系统调用、FFI、动态加载接口都会选择 C 外壳。

extern "C" {
struct EngineHandle;

EngineHandle* engine_create(void);
void engine_destroy(EngineHandle* handle);
int engine_render(EngineHandle* handle, const char* path);
}

这个接口隐藏了 C++ 实现。 调用方只拿不透明指针。 资源释放由显式 destroy 完成。 这不如 RAII 舒服，但 ABI 稳定性更强。

可见性控制是动态库卫生

默认导出所有符号会污染全局符号空间。 动态库应该默认隐藏，只导出明确的公共 ABI。

#if defined(_WIN32)
#define API __declspec(dllexport)
#else
#define API __attribute__((visibility("default")))
#endif

extern "C" API int engine_version(void);

配合编译选项：

c++ -fvisibility=hidden -fvisibility-inlines-hidden -shared engine.cpp

这能降低符号冲突、减少 ABI 暴露面，也让审计更明确。

链接错误要按层定位

常见错误不要只看最后一行。 要问“哪个阶段无法履约”。

链接器报错往往是最早暴露问题的地方。 如果强行绕过，运行时成本更高。

启动代码和运行时也在链接链路里

main 不是进程执行的第一条用户级路径。 真正入口通常在 C runtime 启动代码中。 它负责初始化运行时、全局对象、TLS、标准库状态，然后调用 main。

_start
  -> libc startup
  -> 初始化全局对象
  -> main(argc, argv)
  -> 执行退出处理
  -> 析构静态对象

全局对象初始化顺序问题、动态库 constructor、atexit 处理都在这条链路上。 因此“不要把复杂逻辑放进全局构造”不是风格偏好，而是启动可观测和故障隔离要求。

异常 ABI 是跨边界高风险点

C++ 异常不是简单的跳转。 它涉及栈展开、类型匹配、析构调用和运行时元数据。 异常跨动态库、跨编译器、跨语言边界时，ABI 必须一致。

工程建议：

• 不让异常穿过 C ABI。
• 不让异常跨插件边界。
• 边界层捕获异常并转换为错误码。
• 保证资源释放由 RAII 或显式 cleanup 承担。
• 记录异常路径的日志和审计信息。

extern "C" int plugin_run() noexcept {
  try {
    return run_impl();
  } catch (...) {
    return -1;
  }
}

版本化 ABI 要主动设计

稳定 ABI 不是“以后不改”。 稳定 ABI 是把变化空间提前设计出来。

typedef struct EngineApi {
  uint32_t size;
  uint32_t version;
  int (*render)(const char* path);
  void (*destroy)(void);
} EngineApi;

size 允许扩展结构体。 version 允许调用方判断能力。 函数指针让插件表保持明确。 这类设计比直接导出 C++ 类更适合长期兼容。

产物审计要进入 CI

二进制边界需要机器检查。 至少应该保存：

• 完整链接命令。
• 编译器和链接器版本。
• 导出符号列表。
• 动态库依赖列表。
• ABI 检查结果。
• 调试符号或符号映射。
• 构建哈希和源码版本。

nm -D --defined-only libengine.so | sort > exported-symbols.txt
readelf -d app > dynamic-section.txt
ldd app > runtime-libs.txt

这些文件让线上故障有证据可追。 没有证据链，回滚和降级只能靠猜。

设计取舍

链接器让大型程序可以分模块构建。 动态库让部署和插件化更灵活。 ABI 让不同编译单元可以互相协作。 代价是：源码层面的封装无法自动保证二进制层面的兼容。 C++ 抽象越多，ABI 暴露时越要谨慎。

工程清单

• 公共头文件必须单一来源。
• 跨动态库边界优先使用 C ABI 外壳。
• 默认隐藏符号，只显式导出公共接口。
• 不在 ABI 边界暴露 STL 容器和异常。
• 为插件接口设计 version 和 size。
• 保存链接命令和导出符号。
• 用 nm、readelf、objdump 排查链接证据。
• 把 ABI 变更纳入审计和发布说明。
• 为动态库加载失败设计降级路径。
• 在 CI 中检测符号漂移。

小结

目标文件、链接器和 ABI 决定了源码之外的程序形态。 如果只理解语法，就会把二进制边界问题误判为偶发故障。 可靠的 C/C++ 工程必须把 API、ABI、构建产物、运行时加载和审计记录当作同一套系统来维护。