Wild项目中的AArch64架构链接问题分析与解决方案

在开发Wild项目的过程中，我们遇到了一个关于AArch64架构下链接器错误的技术问题。这个问题涉及到GOT（Global Offset Table）内存分配不一致的情况，具体表现为链接器在分配.got段空间时出现了预期与实际值不匹配的错误。

问题现象

当尝试链接mold项目时，系统报告了以下错误信息：

Error: Unexpected memory offsets:
Part #5 (section `.got` alignment: 8) expected: 0x7907d0 actual: 0x7907b0 bumped by: 0x340 requested size: 0x360

这个错误表明在.got段的分配过程中，预期分配的内存地址与实际分配的内存地址存在0x20（32字节）的差异，这恰好对应4个GOT条目的大小。

问题根源分析

通过深入调查，我们发现问题的根源在于对TLS（Thread Local Storage）符号的处理上。具体来说，系统在处理_ZSt15__once_callable和_ZSt11__once_call这两个符号时，为它们分配了不必要的GOT条目：

1. 对于每个符号，系统分配了：
   • 1个GOT条目用于GOT_TLS_OFFSET
   • 2个GOT条目用于GOT_TLS_DESCRIPTOR

然而，实际上这些符号只需要GOT_TLS_OFFSET条目，因为它们是通过R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC和R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21重定位类型引用的，这些类型只需要GOT_TLS_OFFSET条目。

技术背景

在AArch64架构中，TLS访问有三种主要方式：

1. 传统TLS访问模型：

   • 使用GOT_TLS_OFFSET和GOT_TLS_MODULE组合
   • 每个TLS符号被分配一个(module ID, offset)对

2. TLSDESC模型：

   • 使用GOT_TLS_DESCRIPTOR
   • 更高效的TLS访问机制

3. 初始执行模型：

   • 使用GOT_TLS_OFFSET单独
   • 适用于已知在执行时已加载的TLS变量

在我们的案例中，系统错误地为只需要GOT_TLS_OFFSET的符号分配了额外的GOT_TLS_DESCRIPTOR条目，导致了内存分配不一致。

解决方案

经过分析，我们确定了以下解决方案：

1. 精确匹配重定位类型与GOT条目需求：

   • 对于R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC和R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21重定位，只分配GOT_TLS_OFFSET条目
   • 不自动为这些符号分配GOT_TLS_DESCRIPTOR条目

2. 保持ABI兼容性：

   • 确保解决方案不影响现有的TLS访问ABI
   • 支持混合使用不同TLS访问模型的情况

3. 验证测试：

   • 创建了最小化测试用例验证修复效果
   • 确保修复不会引入新的回归问题

经验总结

这个问题的解决过程给我们带来了几个重要的经验教训：

1. 链接器内存分配一致性：

   • 必须确保符号解析、地址分配和实际写入三个阶段保持严格一致
   • 任何不一致都可能导致难以诊断的链接错误

2. TLS处理复杂性：

   • 不同架构和ABI对TLS的处理方式差异很大
   • 需要仔细理解每种重定位类型的实际需求

3. 调试技巧：

   • 使用WILD_SAVE_BASE隔离链接过程
   • 通过打印关键路径信息定位问题
   • 创建最小化测试用例验证假设

这个问题最终通过精确匹配重定位类型与GOT条目需求得到了解决，确保了Wild项目在AArch64架构下的稳定链接能力。这个案例也展示了系统级软件开发中理解底层ABI和架构特性的重要性。