Wild项目中AArch64架构下__gmon_start__符号处理问题分析

在Wild项目开发过程中，开发团队遇到了一个关于AArch64架构下符号处理的特殊问题。这个问题涉及到编译器运行时初始化对象(crti.o)中的__gmon_start__符号处理，以及动态链接过程中的重定位机制。

问题现象

在AArch64架构下运行测试时，系统报错提示无法为__gmon_start__符号应用复制重定位(copy relocation)。错误信息显示该符号被标记为本地(local=1)，位于动态链接库中。通过分析发现，crti.o对象文件中确实定义了这个符号，但被标记为弱引用(WEAK)和未定义(UND)。

技术背景

__gmon_start__是GNU性能分析工具gprof使用的特殊符号，通常由运行时库提供。在程序启动时，如果这个符号存在，gprof会用它来初始化性能分析功能。在AArch64架构下，编译器生成的代码会使用三种不同类型的重定位来处理这个符号：

1. ADR_GOT_PAGE重定位 - 用于获取GOT页地址
2. LD64_GOT_LO12_NC重定位 - 用于加载GOT条目
3. JUMP26重定位 - 用于函数跳转

相比之下，x86架构只使用GOTPCRELX这一种间接重定位方式，不需要复制重定位。

问题根源

通过深入分析发现，Wild链接器在处理这个符号时存在两个关键问题：

1. 符号解析逻辑不够完善，未能正确处理弱未定义符号的情况
2. 重定位处理机制中，对绝对符号和非绝对符号的区分不够细致

具体来说，链接器错误地尝试为未定义的__gmon_start__符号创建复制重定位，但实际上复制重定位需要知道符号的大小，而这是未定义符号所不具备的信息。

解决方案

开发团队通过修改符号处理逻辑解决了这个问题。关键改进包括：

1. 确保不为未定义符号创建复制重定位
2. 完善符号标志位检查逻辑，特别是对绝对符号的处理
3. 增强符号解析的健壮性，正确处理弱引用情况

这些改进使得Wild链接器能够正确处理AArch64架构下对__gmon_start__等特殊符号的引用，同时保持与其他架构的兼容性。

经验总结

这个案例展示了跨平台开发中架构差异带来的挑战。AArch64和x86架构在重定位处理上的不同行为需要链接器有更精细的控制逻辑。同时，也提醒我们在处理特殊符号时需要特别注意其定义状态和引用属性，特别是对于性能分析工具等系统级功能依赖的符号。