请求详解aarch64-none-elf与arm-none-eabi的技术差异

1. 目标架构支持 #

• aarch64-none-elf：专为64位ARM架构设计，核心支持ARMv8-A指令集，同时兼容后续的ARMv9等64位ARM版本，可编译生成AArch64指令集的裸机程序（无操作系统依赖）。
• arm-none-eabi：聚焦32位ARM生态，覆盖ARMv7（含Cortex-A/R/M全系列）、ARMv6及更早的32位ARM指令集（含Thumb/Thumb-2扩展），完全不支持AArch64指令集，尝试编译64位代码会直接触发指令集不兼容错误。

2. 二进制格式与ABI标准 #

两者生成的二进制文件均为ELF格式，核心差异在于遵循的应用二进制接口（ABI）：

• aarch64-none-elf：遵循AArch64 ELF ABI，这是64位ARM专属的ABI规范，定义了64位寄存器调用约定、内存寻址规则、函数参数传递方式等，充分适配64位架构的性能和内存特性。
• arm-none-eabi：遵循ARM EABI（嵌入式应用二进制接口），针对32位寄存器模型和有限内存场景设计，是32位ARM嵌入式系统的通用ABI标准。

3. 典型适用场景 #

• aarch64-none-elf：用于现代64位嵌入式设备、高性能SoC（如手机芯片、ARM服务器处理器、高端工业控制器），以及需要利用64位寻址能力、大内存支持的裸机开发项目。
• arm-none-eabi：主要服务于老旧32位嵌入式系统、低功耗微控制器（如Cortex-M系列MCU）、资源受限的物联网设备，这类场景优先考虑内存占用和低功耗，无需64位架构的性能增益。

额外补充 #

两者均属于GNU交叉编译工具链的分支，包含gcc（编译器）、as（汇编器）、ld（链接器）等核心组件，但针对各自目标架构的指令集、寄存器模型做了深度优化。交叉编译时必须严格匹配工具链与目标架构，否则会出现编译失败、运行时崩溃等问题。

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