Scala Native项目在macOS上使用Homebrew lld 18.1.8时出现SIGBUS问题的分析与解决

问题背景

在Scala Native项目的开发过程中，部分开发者在macOS 15.2系统（M1芯片架构）上遇到了一个棘手的运行时问题。当使用Homebrew提供的lld 18.1.8版本作为链接器时，程序会在测试运行完成后意外抛出SIGBUS信号（信号编号6），导致测试进程异常终止。

问题表现

具体表现为：

1. 测试用例能够正常执行并通过
2. 在测试运行结束后，进程意外终止
3. 错误信息显示"Test runner interrupted by fatal signal 6"
4. 进程返回非零退出码134（0x86）

值得注意的是，这个问题似乎只出现在M1架构的macOS上，在Intel架构的Linux系统上并未复现。

问题根源

经过深入分析，发现问题与以下因素相关：

1. 链接器选择：当使用-fuse-ld=lld选项强制使用LLD链接器时会出现问题
2. 对象文件顺序：LLD链接器对对象文件的链接顺序非常敏感
3. 异常处理机制：Scala Native的异常处理实现依赖于特定的链接顺序

根本原因在于LLD链接器在处理异常处理相关的对象文件时，如果这些文件没有按照正确的顺序链接，就会导致运行时异常处理机制失效，最终引发SIGBUS信号。

技术细节

Scala Native的异常处理机制依赖于以下几个关键组件：

• eh.c：异常处理实现
• UnwindRegistersRestore.S：寄存器恢复汇编代码
• Unwind-EHABI.cpp：异常处理ABI实现
• 其他与栈展开(unwind)相关的实现文件

这些组件需要按照特定顺序链接，以确保异常处理机制能够正常工作。当使用LLD链接器时，如果这些文件没有出现在链接命令的前面位置，就会导致运行时无法正确处理异常。

解决方案

开发团队提出了两种解决方案：

1. 调整链接顺序：手动将异常处理相关的对象文件移到链接命令的前面
2. 使用链接器分组选项：通过-Wl,--start-lib和-Wl,--end-lib选项将相关对象文件分组

最终采用的解决方案是第二种方法，通过链接器指令将异常处理相关的对象文件分组，确保它们被视为一个整体，不受链接顺序影响。这种方法更加健壮，不需要精确控制每个文件的链接位置。

解决方案验证

解决方案经过验证：

1. 在出现问题的M1 macOS系统上测试通过
2. 测试用例能够正常执行并正确退出
3. 不再出现SIGBUS信号导致的意外终止

经验总结

这个案例为我们提供了几个重要的经验：

1. 链接器行为差异：不同链接器（如LLD与系统默认链接器）可能有不同的行为特性，特别是在处理对象文件顺序时
2. 异常处理实现敏感性：低级异常处理机制对运行环境有严格要求
3. 跨平台兼容性：ARM架构与x86架构可能存在细微但重要的差异
4. 构建配置影响：看似无害的构建配置选项（如链接器选择）可能导致难以诊断的问题

对于使用Scala Native的开发者，如果遇到类似的信号中断问题，建议：

1. 检查链接器选择和版本
2. 关注异常处理相关的构建配置
3. 考虑不同平台和架构的潜在差异

这个问题也提醒我们，在复杂的系统编程环境中，工具链的每个环节都可能成为潜在问题的来源，需要全面考虑和仔细验证。