64位PowerPC系统可否使用powerpc-elf ABI替代ELFv2？

背景说明 #

尝试为64位PowerPC架构交叉编译GCC时，会发现GCC没有提供powerpc64-elf目标，仅内置了可生成32/64位代码的powerpc64-linux、powerpc-rtems两类目标。PowerPC64 Linux的ABI规范中引入了名为TOC的额外段，且使用ELFv2格式适配相关变更。

常见疑问解答 #

1. 使用TOC访问全局变量的收益 #

• TOC是为位置无关代码（PIC）高效生成设计的，大型程序中所有全局符号地址集中存储在TOC段，单份TOC即可覆盖所有全局符号访问需求，避免每个编译单元独立重定位全局地址的开销，动态链接场景下可大幅降低重定位表体积与动态链接耗时。
• TOC引入的2条额外指令（加载立即数+加法）开销极低，仅增加1~2个时钟周期，远低于动态链接场景下的全局地址重定位开销。

2. PowerPC是否存在单指令访问全局变量的限制 #

PowerPC架构的立即数编码长度有限：32位模式下单指令最多携带16位立即数，64位模式下单指令最多携带34位有效立即数，无法直接编码64位虚拟地址空间中的任意全局变量地址，因此必须通过地址拼接或TOC间接访问实现全局变量寻址，不存在完全绕开的可行方案。

3. 切换通用PowerPC ABI是否可生成合法64位代码 #

• 修改GCC默认ABI为通用PowerPC ABI后，仍然可以生成合法的64位PowerPC代码，不会出现指令集层面的兼容性问题。
• 64位寄存器、大于4GB的地址空间访问、浮点/向量扩展等硬件特性的支持仅和编译器的指令集配置有关，和ABI选择无直接关联，不会因为切换ABI损失硬件特性支持。
• 自定义ABI场景下需要自行实现对应ABI的启动代码、重定位逻辑、库文件适配，无法直接复用现有powerpc64-linux生态的二进制组件。

自定义OS场景适配建议 #

希望简化跨平台架构支持包、用同一份架构代码适配多平台的需求可以实现：选择32位PowerPC ABI变种扩展64位寻址支持的方案可行，仅需要在链接脚本中明确内存布局，在启动代码中开启64位寻址模式即可，不需要修改GCC后端的核心逻辑。

最终方案说明 #

选择使用标准ABI的方案是合理的：编译器与操作系统的ABI约定是底层适配的核心基础，复用现有Linux、RTEMS等系统的成熟GCC配置方案，可以大幅降低底层适配的工作量，结合GCC后端结构相关的教程即可快速完成自定义目标的GCC配置。

内容的提问来源于stack exchange，提问作者memoks