ARM ABI规范全景解析：从arm-software/abi-aa仓库到编译器后端落地

做交叉编译这些年，我有个根深蒂固的习惯：只要遇到“函数调用传参传得好好的，一优化就炸”这类问题，第一反应不是去翻优化选项，而是去查编译器到底按哪一套 ABI 来生成代码。ABI 全称 Application Binary Interface，在 ARM 生态里最核心的公开资料就是 GitHub 上的 arm-software/abi-aa 仓库。标题里的 Arm-abi-aa，我理解就是这套仓库所承载的、面向 ARM A Profile（Application Profile）架构的一整套二进制接口规范。这篇文章我会把它拆开来讲：仓库里到底有哪些规范文档，怎么用源码审计的思路去跟踪这些规范的变更，以及真正落地到编译器后端时，这些规范如何翻译成寄存器分配、栈帧布局和重定位逻辑。无论你是做交叉编译工具链、RTOS 适配，还是准备接 AArch64 服务器生态，这篇都能省下你不少查文档的时间。

1. 这个标题到底在说什么：Arm-abi-aa 全景与读者画像

1.1 Arm-abi-aa 到底是什么

先从命名说起。“arm-software/abi-aa”是 ARM 官方在 GitHub 上维护的 ABI 规范仓库，里面的 “aa” 不是某个玄学缩写，而是 ARM 架构分类里的 A Profile，也就是 Application 架构档位。ARM 处理器大体上按 A/R/M 三个 profile 划分：A Profile 跑 Linux、Android、服务器虚拟化这类完整应用环境，R Profile 做实时控制，M Profile 做单片机嵌入式。Arm-abi-aa 这个仓库关注的，就是 A Profile 架构下的过程调用标准、ELF 文件格式、DWARF 调试信息、C++ ABI、异常处理和运行时辅助函数的规范集。

ABI 和 API 是两回事。API 告诉你在源码层面怎么调用一个函数，ABI 告诉你在二进制层面这个函数的参数放哪里、返回值放哪里、栈怎么对齐、异常表长什么样。我经常用一句话类比：API 是前台接待的话术表，ABI 是水管工手里的施工图。编译器就是那个水管工，照着施工图把函数调用焊死。施工图版本不一致，表面上看水能流，一加压整个楼就崩了。这也是为什么“编译器版本升级后，链接老库就段错误”这类问题，最后往往都能回溯到 ABI 不一致。

顺便说一句，ABI 文档不一定只在 arm-software/abi-aa 里，AAPCS32/AAELF32 这些 32 位规范也有独立来源，但这个仓库把 AProfile 的 AArch32/AArch64 规范集中成了开源 Markdown/AsciiDoc 源码，大大降低了查阅和审计的门槛。

1.2 哪些人必须搞懂这些规范

不是所有人都需要把每个章节啃完，但下面这几类人，迟早都要和这套规范正面相遇。

第一类是交叉编译工具链开发者。你要维护一个基于 LLVM 或 GCC 的 ARM 后端，调用约定、栈帧布局、重定位生成全部绕不开 ABI。第二类是 BSP 和 RTOS 工程师。在裸机或 RTOS 上做启动代码、任务切换、异常处理时，如果不清楚 AAPCS64 的寄存器保存规则，写出来的切换代码就可能在中断返回时把现场搞坏。第三类是二进制安全、沙箱、JIT、二进制翻译方向的开发者。你要拦截或模拟函数调用，就必须精确知道哪些寄存器是 caller-saved、哪些是 callee-saved，栈对齐是多少。第四类是纯粹做 ARM Linux 应用移植的工程师。虽然你可以不读规范，但当同一个 .so 在不同工具链版本下出现诡异崩溃时，你至少得知道该去哪里查，以及怎么把“ABI 不匹配”这几个字说清楚。

所以这篇文章不是教你把每个文档背下来，而是给你一张地图、一套审计方法和几个落地验证手段，让问题出现时你能快速定位到规范层而不是瞎猜。

2. 源码审计：把 ARM-software/abi-aa 仓库拆开看

2.1 仓库结构解剖与规范地图

“源码审计”听起来很吓人，但这个仓库的“源码”不是 C 代码，而是规范文档的源文件。也就是说，你可以用 git 来追踪每一版 ABI 规范的改动，这是传统 PDF 文档做不到的事。

我拉下仓库后，习惯先把顶层文件按功能归成几类。举一个最常见的分类维度。

这些规范之间不是孤立的。举个最常见的链路：你写一个返回大结构体的函数，前端根据 AAPCS64 决定用 x8 传隐藏的返回地址指针；后端生成调用指令时，必须用 AAELF64 规定的重定位类型；如果函数里有 try/catch，还要把异常范围表按照 C++ ABI 和 AAEABI 的格式排布好，最后调试时又依赖 AADWARF64 才能让栈回溯正确。所以做编译器落地时，动不动就得同时开三四个规范文档。

2.2 审计方法：读文档不如读历史

我对这个仓库做审计时，最常用的不是从头到尾读，而是先看 git 历史。ABI 规范不是一成不变的，尤其这几年 ARM 在 SVE、SME、Feature Telemetry 上不断扩充指令集，调用约定和重定位规则也在跟着调整。今天照着一份三年前的 PDF 写编译器，出来的代码放到最新的 GCC/Clang 链接，很可能链都链不过。

我的审计流程现在是固定的。

第一步，把仓库 clone 到本地，保持和上游同步。原仓库很大，但只做规范查阅的话，clone 一次就够了，后续定期 fetch。

第二步，用 git log 看最近改动。比如想看 AAPCS64 的变更记录，我会执行类似这样的命令：

git clone https://github.com/ARM-software/abi-aa.git cd abi-aa git log --oneline -30 -- 'aapcs64*' git diff HEAD~10..HEAD -- 'aaelf64*'

这个命令会列出最近 30 条涉及 AAPCS64 文件路径的提交，以及最近 10 次提交对 AAELF64 的改动。文件名和路径在不同版本里可能略有变化，用通配符就可以避开结构不一致的问题。关键信息在 commit message 里，ARM 官方团队习惯在提交信息里写清楚“Add support for FEAT_*”或者“Clarify HFA/VHA rule”，扫一遍就能知道规范在哪个方向演进。

第三步，上 GitHub 的 issue 区看一眼。很多 LLVM/GCC 编译器开发者会在 issue 里报告规范条文的歧义，或者是自己实现时遇到的边界情况。这些讨论比规范正文更能暴露真实落地时的坑。

第四步，把文档构建成 HTML，方便全文检索。这个仓库的文档多数是 AsciiDoc 或 Markdown 格式，本地装了 asciidoctor 后，一条命令就能生成 HTML：

asciidoctor aapcs64.adoc -o /tmp/aapcs64.html

构建出来以后，我通常会在浏览器里开三个标签页：AAPCS64、AAELF64、AAEHABI，配合 grep 一起用。比如要查“long double 怎么传参”，直接全文搜 long double，比一页一页翻快得多。

2.3 构建与交叉验证

规范文档构建只是第一步，真正的审计要落在“规范和自家工具链的版本对应关系”上。我的做法是维护一张版本映射表，记录仓库里哪个 commit 对应我自己维护的工具链基线。

举个例子：Clang 18 分支在实现 AArch64 后端时，会把 arm-software/abi-aa 的某个 commit 作为 ABI 依据。如果我在审计时发现该 commit 之后 AAPCS64 增加了一条关于 SVE2 参数传递的修订，就需要评估这条修订是否会影响我已经编译出来的库。这不是理论问题，SVE 刚推出来时，GCC 和 LLVM 对向量参数的处理就出现过差异，最后追根溯源都是因为两家实现参考的 ABI 规范版本不同。

交叉验证还有一个土办法，就是直接用 readelf 和 objdump 检查自己编译出的二进制，看里面的属性和重定位是否和最新规范一致。比如 AArch64 ELF 文件里的 Tag_ABI_VFP_args、Tag_FP_arch 这些处理器特定属性，在 readelf -A 输出里直接能看见。这些属性属于 AAELF64 规范的一部分，但实际编码在对象的 ARM attributes 段里，做审计时最好单独对它们做一次快照对比。

3. 编译器开发落地：从 ABI 条款到后端代码

3.1 调用约定如何翻译成 Lowering 规则

如果要在 LLVM 里为 AArch64 写后端，第一个绕不开的文件就是AArch64CallingConv.td。这个文件做的事，就是把 AAPCS64 的“参数放哪、返回值放哪”翻译成 TableGen 规则。

简化以后，思路大概是这样的：

// 概念示意，不是 LLVM 源码完整拷贝 def CC_AArch64_AAPCS : CallingConv<[ // 64 位整数参数依次使用 X0-X7 CCIfType<[i32, i64], CCAssignToReg<[X0, X1, X2, X3, X4, X5, X6, X7]>>, // 32/64 位浮点参数依次使用 S0/D0 所在的 V 寄存器 CCIfType<[f32, f64], CCAssignToReg<[S0, S1, S2, S3, S4, S5, S6, S7]>>, // 128 位向量参数用 Q0-Q7，HFA/HVA 另走专门逻辑 CCIfType<[v16i8, v8i16, v4i32, v2i64, v4f32, v2f64], CCAssignToReg<[Q0, Q1, Q2, Q3, Q4, Q5, Q6, Q7]>>, // 寄存器不够了，按参数类型大小压栈 CCIfType<[i32, i64, f32, f64], CCAssignToStack<4, 8>> ]>;

当然，真正的实现比这个复杂得多，因为还要处理 HFA/HVA、变参函数、按引用传递的大结构体、单独划分的 indirect result。但核心思想是固定的：调用者和被调用者各自编译时都遵循同一套规则，哪怕一个用 Clang、一个用 GCC，只要它们都实现对了 AAPCS64，二进制之间就能无缝互调。

为什么这个文件那么重要？因为如果你在这里写错一个寄存器的顺序，比如把浮点参数错放到了 X 寄存器，那调用者把float放到 S0，被调用者却去 X0 里找，这个函数 100% 跑不对。而且这种错不会在单独编译时暴露，只有把调用方和被调用方分别编译再链接时才会崩。

3.2 栈帧布局与代码生成约束

AAPCS64 对栈的要求可以用一句话概括：在函数入口点，SP 必须保持 16 字节对齐，并且在 public interface（也就是函数调用边界）处始终如此。这意味着编译器生成 prologue 和 epilogue 时，不仅要保存寄存器，还要保证分配完局部变量后 SP 还是 16 的倍数。

一个非常典型的 AArch64 函数开头是：

stp x29, x30, [sp, #-16]! // 保存帧指针和返回地址，同时 SP -= 16 mov x29, sp // 建立新的帧指针 sub sp, sp, #32 // 分配局部变量空间，保持 16 字节对齐 ... ldp x29, x30, [sp], #16 // 恢复帧指针和返回地址，同时 SP += 16 ret

第一句里的!表示先更新 SP 再访存，也就是一种 pre-index 的前递减操作。这种写法在 AArch64 里非常常用，能够用一条指令同时完成“保存寄存器”和“调整栈指针”。编译器在实现时，需要精确计算好每个函数需要的栈空间，并且把 SP 调整量对齐到 16 字节。

还有一点经常有人忽略：SP 在 AArch64 里不能像通用寄存器那样随便参与算术逻辑运算，很多指令集编码对 SP 的使用有限制。所以像mov x0, sp可以，但某些加法指令不能直接写回 SP，编译器必须用add sp, sp, #imm这种专门形式。这些细节都在 AAPCS64 的栈约束章节里写着，写后端时很容易因为手滑生成一条非法指令。

3.3 ELF 重定位与 C++ ABI 的连带影响

函数调用约定只是 ABI 的地基，地基上面还压着 ELF 重定位和 C++ ABI 两座楼。

先说重定位。AArch64 的指令定长 32 位，一条bl指令根本装不下完整的 64 位目标地址，所以 AAELF64 定义了一大堆重定位类型来配合链接器做地址解析。比如R_AARCH64_CALL26对应bl指令，R_AARCH64_ADRP_PREL_PG_HI21配合R_AARCH64_ADD_ABS_LO12_NC用于加载一个全局变量地址。编译器后端在生成adrp/add序列时，必须给汇编器或者链接器输出正确的重定位信息，否则地址差 4KB 对齐都可能算错。

C++ ABI 则是另一套让人头疼的东西。AArch64 上的 C++ ABI 继承了 Itanium C++ ABI 的框架，但做了 ARM 侧修订，包括名称修饰规则、vtable 布局、RTTI 结构等。如果你做的是 C 编译器，这些可以暂时不看；但一旦要支持 C++，异常处理就必须把.eh_frame和 personality routine 接上。注意这里 AArch64 和 AArch32 有本质区别：AArch32 经常使用.ARM.exidx做异常展开表，而 AArch64 更接近 x86_64 的模式，使用.eh_frame和 DWARF 展开方式。移植老代码时最容易踩的坑，就是把 32 位的异常处理实现直接搬到 64 位项目里，结果栈回溯全断，异常也 catch 不到。

3.4 验证闭环：测试用例与反汇编比对

规范写得再清楚，最后都要用测试来验证编译器是否真正遵守。我每次改完调用约定相关的代码，都会先跑一组最小的 ABI 测试矩阵。

我先写一组 C 函数，覆盖这些场景：

struct Pair { double a, b; }; struct Pair make_pair(double a, double b) { return (struct Pair){a, b}; } long long sum8(long long a1, long long a2, long long a3, long long a4, long long a5, long long a6, long long a7, long long a8) { return a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8; }

然后用目标编译器编译并生成汇编：

clang --target=aarch64-linux-gnu -O2 -S test.c -o test.s cat test.s

对照 AAPCS64，sum8的 8 个参数应该全部落在 X0-X7 上，整个函数体里不应该出现从栈读参数的指令。make_pair返回一个包含两个 double 的结构体，按 HFA 规则应该在 V0 和 V1 返回，而不是放进 X0/X1。如果你实现的编译器把 HFA 错判成普通 composite，这里反汇编一看就能发现。

再写一个返回超过 16 字节结构体的函数，反汇编里应该有对 X8 的赋值或者使用。X8 在 AAPCS64 里的一个关键作用是 indirect result location，也就是大结构体返回时由调用者传入隐藏地址。如果编译器忘了把结果地址写到 X8，被调用者把数据写到错误内存，程序一跑就是个段错误。

4. 经典坑位与排查实录

4.1 结构化数据类型一直是重灾区

我做编译器落地这几年，结构化数据的传参和返回占掉了至少一半的 ABI bug。最典型的是大结构体返回。

比如一个函数签名长这样：

typedef struct { unsigned char data[64]; } BigStruct; BigStruct make_big(void);

AAPCS64 规定这种超过 16 字节的 struct 按引用返回。调用者需要在自己的栈上预留空间，然后把地址放进 X8，再调用make_big，被调用者把结果写到 X8 指向的内存。如果某个后端实现漏掉了 X8 这个隐藏参数，被调用者可能把返回值写到某个临时栈地址，等函数返回后那个栈地址已经无效，调用者读到全是垃圾。

另一个高发区是 HFA 的判定。HFA 全称 homogeneous floating-point aggregate，指由同一浮点类型成员组成的聚合类型，成员数量不能超过 4 个。比如struct { double a, b, c, d; }是 HFA，可以按 V0-V3 传参；但如果混入了float和double，或者成员里夹了一个int，它就不是 HFA，整体要按普通 composite 处理。这个判定逻辑一旦写错，你和 GCC 编译的两个模块就永远无法正确互调。

还有位域。AAPCS 对位域的存储布局有一套复杂的规则，32 位和 64 位架构上的实现也有差异。如果同一个结构体在 AArch32 和 AArch64 上分别编译，两个二进制互相传数据，位域的偏移很可能完全对不上。这种问题非常阴，因为 C 编译器不会报错，只有数据错乱。

4.2 工具链混用和环境差异

很多同学并不是在写编译器，只是同时装了多个工具链，然后被 ABI 差异折磨。ARM 生态里最常见的两类例子，一类是 AC5（armcc）和 AC6（armclang）混链，一类是软浮点和硬浮点库混用。

AC5 是比较老的 ARM 编译器，Keil MDK 里很多人还在用 ARM Compiler 5.06，也就是热词里常被搜的 AC5；AC6 是 ARM Compiler 6，基于 Clang。这两个编译器遵循的 ABI 细则存在差异，尤其是结构体对齐、位域布局和 C++ 异常处理方面。同一个老库用 AC5 编出来，新工程用 AC6 直接链进去，表面上能链接成功，但运行时可能随机崩溃。我处理过好几次类似问题，最后方案只有一个：把参与混链的库统一用同一套编译器、同一个优化档重新编译，别贪图省事混着用。

软浮点和硬浮点的冲突则是另一个经典事故。AArch32 时代，GCC 有arm-linux-gnueabi和arm-linux-gnueabihf两个目标，前者用软浮点 ABI，浮点参数通过通用寄存器或整数寄存器传递；后者用 VFP 寄存器传浮点参数。把两个版本编译出的 .so 混在一起，链接时经常出现__aeabi_dadd等辅助函数未定义的错误，或者参数传递完全乱掉。判断方法很简单：

readelf -A your_binary.so | grep Tag_ABI_VFP_args

如果输出是Tag_ABI_VFP_args: VFP registers就是硬浮点，如果不是 VFP registers 就是软浮点或软浮点变体。两个不一致的库放一起，老老实实重编其中一个。

4.3 常见问题速查表

这张表我贴在公司内部文档里很久了，基本覆盖了日常能遇到的 80% 的 ABI 类问题。排查顺序永远是：先确认所有参与链接的二进制目标架构一致，再确认浮点属性一致，再看调用约定相关的反汇编，最后查 C++ 异常语义。

5. 落到项目里，我的几条实操建议

如果是做应用层开发，我不建议你从头去读整个 AAPCS64。工作时间宝贵，遇到问题时知道怎么查、怎么验证，比死磕规范更有价值。但如果你给我丢来一个“我来维护交叉工具链”的活，那我会先做三件事。

第一件事，建立 ABI 基线。把当前使用的编译器版本、arm-software/abi-aa 仓库的对应 commit、系统库的版本都记录到一个文档里。以后任何一次工具链升级，先对照这份基线评估差异，再决定要不要全量重编译。AArch64 生态迭代太快，规范版本一直在动，光靠脑子记迟早出事。

第二件事，搭一个最小的 ABI 回归测试工程。不用复杂，几十个 C 文件就够了：整数参数、浮点参数、HFA/HVA、大 struct 返回、Vector 返回、long double、位域结构体、C++ 异常。每次改编译器或者升级工具链，就用不同优化级别编译一遍，然后跑静态检查和实际调用。这个工程量一天能完成，但能省下后面几周的排查时间。

第三件事，把 abi-aa 仓库挂到 CI 里。每次上游有新的 commit，让 CI 自动拉取并 diff 出有改动的规范文件，给我发一个提醒。我不一定每次都细看，但至少知道“AAPCS64 最近更新了”，等下次编译器升级时就有心理预期。

最后再分享一个我常用的土办法：用objdump -dr同时看两份编译器生成的汇编和重定位，很多隐藏的 ABI 差异一眼就能看出来。我曾经帮同事排查一个“AC5 编的库在 AC6 工程里偶发性崩溃”的问题，两个编译器编译同一个头文件里的结构体，-dr一对比，发现结构体成员偏移差了 4 字节。那一刻我比读十遍规范都清醒：ABI 这种东西，文档要读，但最终还是要落到二进制差异上才能让人信服。