Wild链接器处理GLOB_DAT重定位时忽略Addend导致程序崩溃问题分析

在开源项目Wild链接器的开发过程中，开发团队发现了一个与动态链接相关的严重问题：当使用Wild链接OpenH264测试套件时，程序会在运行时出现SIGSEGV段错误，而使用传统的GNU ld链接器则能正常运行。经过深入分析，这个问题揭示了动态链接过程中重定位处理的一个关键差异点。

问题现象

开发者在构建OpenH264项目时发现，使用Wild链接器生成的测试程序在运行时会触发段错误，具体发生在标准输出流操作期间。错误回溯显示问题源于C++标准库中basic_ostream的sentry构造函数，这表明可能与I/O系统的初始化有关。

根本原因分析

通过详细的对比调试，团队发现了几个关键差异点：

1. 符号处理差异：Wild与GNU ld在处理弱符号和强符号时存在不一致。当存在弱符号引用但实际有强符号指向同一地址时，GNU ld会为强符号生成复制重定位，而Wild最初版本则直接为弱符号生成重定位。

2. 重定位类型选择：对于数据段中的重定位，Wild使用了R_X86_64_GLOB_DAT类型，而GNU ld则使用R_X86_64_64类型。虽然理论上这两种类型都用于存储符号地址，但关键区别在于对addend(附加值)的处理。

3. 运行时加载器行为：较新版本的glibc运行时加载器会忽略R_X86_64_GLOB_DAT重定位中的addend值，这导致Wild生成的程序中某些关键数据结构的虚表指针偏移计算错误。

技术细节

在C++标准库实现中，basic_stringstream的虚表(vtable)指针初始化依赖于重定位。原始对象文件中包含一个R_X86_64_64重定位，指定了虚表地址加上40字节的偏移量。Wild将其转换为R_X86_64_GLOB_DAT重定位后，运行时加载器忽略了addend(40)，导致程序访问了错误的虚表位置。

这种差异在Ubuntu 22.04上不会引发问题，因为其使用的glibc版本仍会处理GLOB_DAT的addend。但在Arch Linux等使用较新glibc的系统上，就会导致程序崩溃。

解决方案

开发团队实施了以下修复措施：

1. 修改符号解析逻辑，确保与GNU ld一致地处理弱/强符号情况
2. 对于数据段中的重定位，避免使用R_X86_64_GLOB_DAT类型，改为使用R_X86_64_64类型
3. 增强链接器差异检测工具，使其能够比较数据段和运行时重定位信息

经验教训

这个案例揭示了几个重要的链接器开发原则：

1. 不同类型重定位的语义差异可能比表面看起来更微妙
2. 运行时加载器的行为可能随版本而变化，链接器需要保持兼容性
3. 对标准库和语言运行时内部机制的深入理解对链接器开发至关重要

该问题的解决不仅修复了OpenH264测试套件的崩溃问题，也提高了Wild链接器在各种Linux发行版上的兼容性，为后续开发奠定了更坚实的基础。