做编译器后端时间久了，你会发现一个很矛盾的现象：明明每天都在和字节、寄存器打交道，但真正遇到“这个结构体为什么这样传参”“这个函数为什么栈上要留 16 字节空洞”这类问题时，大多数人不是去读一手规范，而是先看老编译器发出来的汇编，再反推规则。这套方法在项目里能跑，但风险也大——一旦换了架构、换了优化选项、或者要支持新的数据类型，靠“反推”得到的那点经验就会漏出各种边角问题。
Arm-abi-aa 这个仓库，就是把 ARM 体系下的 ABI 规范文档集中管理起来的源头。写这篇深度源码评测，是因为我最近在做一个面向 ARM 的编译器后端适配，正好把仓库里的 ABI 规范和实际代码生成对照着重读了一遍。这篇文章不是文档翻译，也不是纯粹讲理论，而是把我眼中整个 ABI 落地链路拆开：仓库里到底放了哪些东西、审计这些规范文档时该从哪下手、编译器前端和后端分别在哪个环节消费 ABI 规则、最后又怎么验证自己写出来的代码生成逻辑和规范一致。适合想做编译器后端、交叉编译工具链、或者被跨平台调用惯例折腾过的人参考。
1. 为什么说 ABI 规范是编译器的“隐形合同”
ABI 全称是 Application Binary Interface，直接翻译成应用二进制接口。很多人把它理解成一个“约定”，但实际上它更像一份合同，约束的是编译产物在二进制层面的行为：函数参数从左到右怎么摆放、返回地址放在哪、栈帧按多少字节对齐、结构体怎么布局、符号名会被修饰成什么样子、重定位条目又该怎么描述。只要两个编译单元遵守同一份合同，哪怕一个用 GCC 编、一个用 LLVM 编，甚至在 C 里调汇编，都能正确协作。反过来，只要有一个环节违背合同，轻则参数读错，重则整个程序运行到一半静默崩溃。
我见过太多排查“低概率偶发崩溃”的现场，最后定位到的问题都特别基础：结构体里某个字段的对齐算错了，或者把 32 位参数塞进了 64 位寄存器的高位没做符号扩展。这类问题在单一工具链环境里很难暴露，因为自家编译器、自家库、自家汇编代码互相之间其实共享了同一个“坏习惯”。只有到了做真正的多工具链混合或者跨架构移植时，ABI 的价值才会爆炸式显现。
所以我给刚入门的人一个建议：不要先抓着一堆开发板的裸机代码看，而要把 ABI 规范当成一份“接口文档”来读。有了这份文档，你再看编译器生成的汇编，看到的不是一串串指令，而是“它把每个变量安顿到了 ABI 要求的物理位置”。再看链接脚本和反汇编符号表，也会明白哪些符号是 ABI 约定的产物，哪些才是软件层真正的逻辑符号。
这个仓库的意义正在于此。arm-abi-aa 把各个主题的规范分开管理，比如针对 AArch64 的 AAPCS64（过程调用标准）、针对 ELF 文件格式的补充、C++ ABI 扩展等等。它不是把几百个 PDF 随便堆在一起，而是以源码形式存放，方便提交 issue、做版本 diff、甚至由工具链直接抽取其中的结构化数据。
1.1 规范仓库里的“三层结构”必须先分开
审计这个仓库，第一步不是急着看某个具体关键字，而是先区分 ABI 的三个作用面：
- 语言无关 ABI：描述 ELF 文件格式、重定位、动态链接、异常展开信息等，和“用 C 还是 C++ 写的”没有任何关系。任何编译成 ELF 的程序都必须遵守。
- 语言相关 ABI：描述一个语言特性怎么落到二进制层。比如 C++ 的 vtable 布局、typeinfo 结构、构造函数和析构函数的调用方式。C 语言本身没有复杂对象模型，相关 ABI 通常集中在对齐、位域、setjmp/longjmp 这类行为上。
- 处理器相关 ABI：描述特定架构下的大端小端、自旋锁指令、缓存行对齐建议、原子操作指令序列等。这部分其实是架构手册和 ABI 文档的交叉地带。
很多人把这三个层面混在一起看，结果就是：查参数传递时，翻到了 ELF 重定位章节；验证结构体布局时，又翻到了 C++ 异常处理的内容，导致越看越乱。仓库如果按照“平台总览 / ABI 主题 / 附录”组织文档，那你的阅读策略也应该对应地拆成“先总览，再主题，后细节”。
以 AAPCS64 为代表的过程调用标准，覆盖的是“函数调用边界”：参数放在哪些寄存器、超出寄存器容量放到栈的什么位置、返回大结构体时是否用 x8 作为隐式指针、叶子函数能不能不保存某些寄存器、哪些寄存器是 caller-saved 哪些是 callee-saved。这些内容在编译器后端代码里通常体现为“Value 到物理寄存器”的搬运逻辑，但它更底层的判断依据却在 ABI 文档里。
1.2 从源码审计角度看官方仓库的可追踪性
我做源码审计时习惯关注一个指标：文档的可追踪性。仓库用文本组织规范，最大的好处就是每个章节都有稳定的锚点，理论上可以用脚本对照文档段落和后端代码的注释。即使没有精确到每个句子，至少在版本升级时能快速看出哪一块规则被修改了。
另外，仓库里经常带着各种 appendices 和历史修订说明。例如某个规范会记录“为什么要引入新的伪指令”“为什么某个原来可以出现在任意位置的汇编句子现在不允许了”。这些历史修订信息对编译器开发者特别重要，因为你的代码生成逻辑如果固化了某个“过时行为”，在旧版本上可能没问题，但用新版规范审计时就会暴露出规则冲突。
从源码审计的另一个角度看，ABI 仓库本身就是“活文档”。规范源文件不仅给人看，还会被一些工具链流程引用，比如生成 C 结构体的检查工具、生成寄存器列表的脚本。因此我在本地镜像这个仓库后，不只是把它当成 PDF，而是当成一组可检索的文本数据源来处理，后面审计阶段会聊到具体怎么用。
2. 仓库全景：目录级拆解与各文档的消费时机
如果只看标题里的“arm-abi-aa”，你可能会以为这只是一个单一 ABI 文档的仓库，真正点开之后才会意识到它是一组规范矩阵。为了表达更精确，我先以自己审到的某个版本为参照来描述，文件组织方式可能随版本演进有局部调整，但分类思路长期稳定。
整体上我会把仓库里的内容分成几块：主平台 ABI 文档、ELF 规范补充、C 运行时约定、C++ ABI 约定、专用领域附加文档。这种分法不是目录结构原生的，而是为了对接“编译器哪一阶段会用到哪份规范”设计的。
2.1 主平台 ABI：参数、寄存器、栈和异常的统一出处
AArch64 平台最常见的文档是 AAPCS64（Procedure Call Standard for the ARM 64-bit Architecture）。它规定了通用寄存器 x0-x30 的用途：x0-x7 作为整型参数传入和返回、x8 作为间接结果寄存器、x16/x17 用于 intra-procedure-call 的临时寄存器、x29 是帧指针、x30 是链接寄存器（返回地址）。这些规则直接影响后端的第一层代码：寄存器分配前，函数入口就知道哪些变量已经住在哪个物理寄存器里，退出时又要把哪些值放回调用者期望的位置。
浮点和 SIMD 寄存器也有清晰划分，v0-v7 既用于传参也用于返回浮点类型，v8-v15 有一部分低 64 位需要被调用者保存，v16-v31 作为临时寄存器。编译器后端必须针对“哪一部分寄存器在调用边界保持”做区分，而不是简单地把整个向量寄存器堆都压栈。浪费栈空间还是小事，关键是可能引入不必要的保存与恢复，拖慢函数调用频率高的程序。
AAPCS64 还有栈对齐规则：在函数调用边界，栈指针 SP 要保持 16 字节对齐。这意味着如果一个函数参数列表全塞进寄存器，理论上不需要额外压栈，但一旦出现超过 8 个整型参数，前 8 个放寄存器，剩余参数要从第 0 个栈槽开始连续存放，而且调用前 SP 必须对齐到 16 字节。如果上一个函数消耗了 8 字节栈空间导致 SP 不满足条件，就需要先 sub sp, sp, #16 来做动态对齐。类似这种细节，任何靠“看几个例子”反推的工程都容易漏。
2.2 类型布局与调用约定的联动检查
类型布局是另一个绕不开的部分。C 语言里我们写struct { char a; int b; }，编译器怎么知道 b 要放在偏移 4？答案其实依据的是 ABI 规定的数据模型。在 AArch64 LP64 数据模型下，char是 1 字节、int是 4 字节、long和指针是 8 字节，结构体成员按自然对齐填充。所以这个结构体的布局就是 a 占偏移 0，填充 3 字节，b 占偏移 4。如果换成一个双精度和一个字符，双精度需要 8 字节对齐，结构体总大小也可能变成 16 字节而不是 9 字节。这些看似基础的问题，正是后端在做“合法位偏移计算”时必须消费的数据。
仓库里还有处理更特殊类型的文档，比如向量类型、half 浮点、复数类型。它们在被编译为基本类型时，会遵循“同形同构”的原则，例如 4 个 float 组成的向量和 float32x4_t 在向量寄存器里分配方式一样。审计时如果碰到自定义后端对 new 类型的支持，需要把这种传递规则和寄存器类型同时改掉，只改一边就会产生 ABI 撕裂。
2.3 ELF 规范补充：链接器视角的 ABI 合同
仓库里和 ELF 格式有关的补充文档，会把架构特有的节名、重定位类型、程序头属性说清楚。比如 AArch64 ELF 里要求.got和.plt的架构行为、动态符号的可见性规则、不同代码模块间进行长跳转时可能需要的重定位类型。只做编译器不做链接器的团队，往往会低估这一块，但编译器必须负责生成正确的重定位指令，否则后面的链接阶段会直接失败。
举例来说，在生成-fPIC代码时，访问一个全局变量不能简单adrp + ldr，还要经过 GOT（全局偏移表），因为共享库在加载时才知道符号的最终地址。如何在指令里体现这种“间接寻址”，实际就是 ABI 和 ELF 规范指定的重定位类型。我在后端代码里经常看到的一个 bug 是：针对非 PIC 的 adrp/add 重定位正确处理了，但针对 PIC 的 GOT 重定位漏写了R_AARCH64_ADR_GOT_PAGE或者R_AARCH64_LD64_GOT_LO12_NC，导致生成的 .o 文件可以被汇编，但链接时出现无法解析的溢位告警。这种问题在文档里其实都能找到对应条目，前提是读者知道去哪一节查。
2.4 C/C++ 运行时库约定：名字修饰与全局构造函数
ABI 仓库还会包括一些和 C/C++ 运行库配合的规则。C 语言里主要是结构体返回、复数运算、整数除法辅助函数等约定；C++ 里则要复杂得多，因为牵扯到名字修饰（name mangling）、异常、RTTI、虚表函数槽偏移、构造与析构协作。例如 AArch64 上 C++ 异常处理采用的就是基于 Itanium C++ ABI 的方法，__cxa_throw、__gxx_personality_v0这些符号虽然听起来像“地下的魔法”，但它们都存在固定符号约定，编译器只要按约定生成调用就行了。
很多做嵌入式 C 的人不理解为什么仓库里要塞 C++ 异常处理的章节。但当产品从裸机 C 代码演进到需要 C++ 模块时，这些人往往又是最先遇到问题的一批。与其在集成时手忙脚乱地改链接参数，不如在源码审计阶段就把这部分的边界在脑子里存个档。
3. 把 ABI 变成代码生成：从类型到参数分配的主路径
编译器很少有人从零开始写，真正落到工程里，一般要么基于 LLVM 做新后端，要么改进 GCC 后端，要么为自研编译器写指令选择器。无论哪种方式，ABI 落地都高度集中在一组机制上：函数调用约定、叶子函数处理、栈帧布局、返回路径、异常展开描述。这一节我会用一个简化例子展示“ABI 规则如何映射成代码”，重点讲清楚每一步背后的依据，而不是让读者背一堆伪代码。
3.1 一个简单函数在 AArch64 上到底发生了什么
假设我们有这样一个 C 函数：
long add_many(long a, long b, long c, long d, long e, long f, long g, long h, long i, long j) { return a + b + c + d + e + f + g + h + i + j; }在 AArch64 的 AAPCS64 下，a 到 h 这 8 个参数会依次进入 x0-x7。i 和 j 已经超过寄存器参数上限，所以它们会由调用者放到栈上。编译器生成函数内部代码时，并不需要特殊标记“哪些参数来自栈”，而是把struct arg_layout告诉指令选择器：前 8 个参数读 x0-x7，第 9 个参数从[sp + 0]处读，第 10 个参数从[sp + 8]处读。
这里有个容易被反推法坑到的细节：栈上参数的位置不是“函数入口当前 sp”，而是“调用者执行 BL 之前设置好的 sp”。由于 AAPCS64 规定调用者负责在调用前把超出寄存器的参数安排到栈上，且 sp 要保持 16 字节对齐，所以被调用函数一进来，它的第 9 个参数就天然位于入口 sp 的偏移 0 处。如果你在这个函数里主动压栈了寄存器，再去取第 9 个参数时就必须用帧指针或专门的栈偏移，不能再用当前 sp 直接取，否则会错位。
用汇编视角大致看，函数开头可能会看到：
// 假设参数来自 x0-x7，栈上还有两个参数 add x0, x0, x1 add x0, x0, x2 ... ldr x1, [sp] // 读取第 9 个参数 ldr x2, [sp, #8] // 读取第 10 个参数 add x0, x0, x1 add x0, x0, x2 ret这还不是完整代码，因为实际编译器会考虑栈帧指针、调试信息、是否使用 x16 做跳板等问题，但它很直观说明了一件事：ABI 规则其实精准告诉了你“在哪个 offset 取数据”。后端实现时只要把getArgOffset的计算公式写对，整个过程就会变得非常机械。
3.2 结构体返回值：x8 和隐式指针的角色
处理结构体返回值，是新手后端最容易写错的地方。如果只按“返回值放 x0”的直觉处理，遇到一个很大的结构体就会不知所措。
AAPCS64 的做法是：如果结构体大小超过 16 字节，或者在内存中无法完全放进寄存器返回时，调用者会提前在栈上或者某个可写区域分配一块内存，并把这块内存的地址放进 x8。被调用者把结果写入这块内存，然后把 x8 的地址原样带回 x0，作为结构体返回的“可见结果”。换句话说，这种情况下 x8 不是普通的临时寄存器，而是承担了返回对象存储地址的作用。
考虑这段 C：
struct Big { long data[8]; }; struct Big make_big(void) { struct Big r; for (int i = 0; i < 8; i++) r.data[i] = i; return r; }如果编译器决定用隐式 sret（结构体返回）来处理，那么调用这个函数的中间代码大约相当于：
void make_big(struct Big *__result) { // 在 __result 指向的内存里填数据 }而在 AArch64 指令集中，__result这个指针往往会被放到 x8。调用者如果忽略这一点，就会把返回值理解成一个寄存器里的标量，轻则丢失数据，重则产生内存越界写。这个问题的深层原因是 C 语言源码层看不到 x8，只有后端和 ABI 层知道 x8 的职责。源码审计的意义也体现于此：当你在差异化的编译流程中开启优化（如尾调用优化）时，如果没有意识到 x8 在某些函数里承担隐式返回指针，就可能在函数结尾错误地释放掉保存返回地址的栈区，最终导致返回后 PC 错乱。
3.3 扩展浮点和向量返回值规则
浮点标量返回时使用 v0，向量类型的返回值也优先选择 v0 及其相邻向量寄存器。举个例子，如果函数返回一个结构体，其中包含两个 double 成员，那么这两个 double 会分别放到 v0 和 v1，而不必像大结构体那样走 x8 隐式指针。很多混合编程时出现“C 函数返回结构体，汇编代码只从 x0 取值”的问题，基本都是因为忽略了这种 HFA（Homogeneous Floating-point Aggregate）规则。
HFA 的中文大致是“同质浮点聚合体”：一个结构体的所有成员都是相同浮点类型，且成员数量不超过 4 时，这个结构体可以按成员顺序放入浮点寄存器返回。如果成员数量超过 4，则不再按 HFA 处理，可能回退到普通内存返回。这个判定规则需要后端在对函数返回类型进行 lowering 时提前判断，不能等寄存器分配阶段再处理。跳过了这个判断，等于编译器自己破坏了 ABI 边界，与使用相同规范编译的库对接时就会出现“编译通过但对不上”的问题。
4. 寄存器别名、栈帧和叶子函数：三个容易翻车的角落
ABI 源码审计不能只看参数怎么传。真正让一个后端在工程上“硬”起来的，是那些日常开发中不会刻意炫耀、但每个函数都会遇到的细节：栈帧怎么组织、通用寄存器在调用边界怎么分工、叶子函数能不能无脑省略保存操作。下面这些内容我都是对照规范和实际反汇编逐步确认过的，值得逐个说。
4.1 通用寄存器的调用约定速查
AArch64 的 AAPCS64 把通用寄存器进行分类，每一类有对应的保存责任：
| 寄存器 | 作用 | 保存责任 |
|---|---|---|
| x0-x7 | 参数、返回值 | 调用者保存 |
| x8 | 间接结果寄存器 / 部分场景的临时 | 调用者保存 |
| x9-x15 | 临时寄存器 | 调用者保存 |
| x16-x17 | IP0/IP1，过程内部调用专用临时候选 | 调用者保存（但编译器通常不依赖） |
| x18 | 平台寄存器，通常被平台预留 | 平台相关 |
| x19-x28 | 被调用者保存的通用寄存器 | 被调用者保存 |
| x29 | 帧指针 | 被调用者保存 |
| x30 | 链接寄存器（返回地址） | 调用者保存（函数返回时隐式有效） |
这张表是后端寄存器分配的基础：如果为某个局部变量分配了 x19，那么函数入口必须把它保存到栈上，返回前再恢复；如果分配了 x0 给某个临时值，那这个值会被默认能跨调用保持，但如果你在函数里又发起一个新的函数调用，分配 x0 的那个值就会被后续调用覆盖，所以编译器必须把跨调用的值尽早挪到被调用者保存寄存器或栈上。这里没有“猜”的空间，完全是机械规则。
x18 在很多系统里被用于平台和调用者之间的互通，某些操作系统将其用于线程本地存储相关的全局指针。如果你直接从通用代码里拿 x18 当普通临时寄存器用，可能在单线程裸机里没问题，但放到线程库或信号处理场景中就会出现诡异数据覆盖。AArch64 编译器后端长期保留对 x18 的“尽量不要碰”态度，不是没原因的。
4.2 栈帧布局原则
函数调用时，栈帧通常由调用者按 16 字节对齐压栈，被调用者再分配自己的局部变量区域。一个常见的布局是：
- 返回地址存放在 x30，如果函数还要调用其他函数，通常会把 x30 压栈保存。
- 帧指针 x29 保存上一帧的栈指针，形成链表，主要用于调试和栈回溯。
- 局部变量从栈指针负偏移方向分配。
AArch64 并没有强制规定每个函数都要有帧指针。在优化级别较高时（比如-O2），编译器可能会完全省略 x29，只用 sp 加减来访问局部变量。这样做能节省两条指令，但调试器往往更难回溯。是否保留帧指针，属于 ABI 允许的优化空间，不属于必须保持一致的部分。审计时要注意的是：工具链可以选不同的“默认帧指针策略”，但必须保证异常展开信息和实际代码行为一致，否则backtrace会断在某个奇怪的函数边界。
用结构体指针链来形容栈帧最直观。想象每个函数是一本书的一页，页脚写着“上一页在哪”。如果程序正常返回，就翻回上一页；如果发生异常，运行时库可以利用页脚的链和展开表找到应该跳到哪个异常处理函数。帧指针 x29 负责维护这个“纸质书签”，而异常展开表则更像目录索引。
4.3 叶子函数为什么可以做出激进优化
叶子函数指不再调用其他函数的函数。因为它不会破坏 x30（返回地址），完全没必要把 x30 保存到栈上。如果一个叶子函数体足够短、不修改被调用者保存寄存器，那它的开启和返回可以直接是：
... ret中间连stp x29, x30, [sp, #-16]!都不需要。这个看似简单的优化，实际是 ABI 的一个重要推论。实现时，后端需要做一次“函数体内没有 call 指令”的分析。很多自研编译器直接省去了这个分析，导致所有函数都无脑保存 x30，虽然结果正确，但代码体积变大，并且违背了调用者对叶子函数模式的一般预期。
还有一种更隐蔽的情况：非叶子函数可能被优化成“尾部跳转”的叶子调用。比如函数 A 的最后一句是return B(x);，那么 A 完全可以不恢复调用者现场的栈，而是直接跳转到 B 的入口，让 B 来替自己返回。这种优化称为尾调用优化（Tail Call Optimization）。如果 ABI 对返回地址的处理没有理解清楚，很容易在做尾调用时漏掉“先把当前 x30 从栈里 pop 出来、再跳转”的细节，最终导致 B 返回时回到 A 的调用者而不是 A 内部。
5. 从规范仓库到自研后端的落地链路
源码审计的终极目标不是“看懂”，而是让规范能够进入编译器的测试体系和代码生成逻辑。我以前做审计时，曾走过一段弯路：把 ABI 文档下载完，用浏览器打开，看完一遍之后觉得自己懂了，但一写代码还是漏洞百出。后来我改变了做法，把审计流程拆成四步，分别对应用法的不同阶段，下面整理出来供参考。
5.1 把规范文本转成机器可查的规则表
仓库里规范文件虽然是文本，但扫描和人工阅读的效率都不够高。我一般会先做一轮半自动提取，把每一条硬性规则抽出来，整理成结构化表格。比如“哪些类型可以作为 HFA 传参”“结构体返回超过 16 字节时使用 x8”“浮点寄存器参数最多 8 个”等。这个结构化的过程本身就是对理解程度的最好测试：如果一条规则你无法用两三句话讲清楚它触发的条件和结果，那大概率还没有真正读懂。
用真实代码项目中常遇到的类型为例。我在做 OpenCL 内建函数时，需要支持double4这样的向量类型作为函数参数。最初我以为是简单的 v0-v3 四个寄存器各自带一个 double。后来审计 HFA 定义，发现前提是结构体成员必须完全一致且不是数组，向量类型不算 HFA，但 AArch64 对向量类型另有规则。这就是一个典型“看起来相似、实际不同”的 ABI 陷阱。如果早期没有把这条规则表查清楚，后面生成的驱动代码在宿主上直接跑挂是必然的。
5.2 对照 LLVM/GCC 的反汇编做差分审计
比纯看规范文档更高效的方式，是找一段已经证明能用的参考实现做差分审计。比如可以写一组边界用例：参数个数分别为 7、8、9；参数类型包含整型、浮点、小结构体、大结构体；返回值分别用标量、两个 double 的 HFA、大数组结构体。然后分别用 Clang 和 GCC 交叉编译成 AArch64 汇编，再看差异。
最终自己后端生成的结果，应该尽量向这些主流编译器靠近，而不是照着自己“理解错了的规范”天马行空。把参考编译器的输出当作“可执行的真值”，配合规范文字一起解释，这样既不会因为参考编译器版本过旧导致落后，也不会因为规范读得太快忽略特殊情况。
差分审计的另一个好处，是能发现参考编译器实现里的平台专用回归。比如某些版本的编译器对-mgeneral-regs-only的处理会强制所有浮点参数走通用寄存器，但标准 ABI 并不禁止浮点寄存器传参。做审计时如果把这种“编译选项造成的变化”和“ABI 规定”混为一谈，就可能被误导。所以我的原则是：只用参考实现的“默认配置”作为基准，遇到开启特殊选项后的行为差异，要回源头文档去找依据。
5.3 用小型运行库验证调用边界
语法层面的对照只能说明汇编长得像，真正能证明 ABI 正确性的指标是“混合编译后能否协同工作”。简单的验证方法如下：
- 用 Clang 编一个调用者文件，调用者里通过函数指针调用一个由你自研编译器生成的函数。
- 用你的编译器编一个被调用者文件，该函数返回值是一个大结构体，内部包含大量运算。
- 把两个 .o 链接到一个可执行文件，跑起来看结果。
更完整的做法是准备一组 ABT（ABI 符合性测试）用例，覆盖整型、浮点、混合结构体、超过 16 字节的结构体、位域结构体、复数、内嵌向量、C++ 异常处理路径等。跑通这些用例本身并不难，难的是让它们在各种优化级别（-O0、-O2、-Os）下都行为一致，因为优化可能引入尾调用差异、寄存器分配差异、栈槽复用差异。
我个人在测试时遇到最多的 bug 集中在三个地方：
- 向量类型或 HFA 结构体返回时，实际用了 x0 而不是 v0；
- 参数较多时，栈上参数偏移计算错误，尤其当编译器为了对齐而往栈里塞了 8 字节 padding 后，偏移要从新的“栈顶”算起；
- 处理
long double时误把它当作 16 字节结构体传递，而 AArch64 上通常有更精细的处理方式，不同系统差异较大，必须按实际平台确认。
这张清单不是标准文档直接给出的，而是很多次联调失败后总结出来的常见病灶。对做编译器后端的新手而言，比消化所有 IEEE 754 细节更有价值的，就是先把这几种“卡脖子”路径跑稳。
5.4 和链接器配合验证重定位
ABI 仓库里很多内容是面对链接器和动态加载器的。作为编译器后端，你生成的目标文件中，每个重定位类型都要和链接器达成一致。如果链接器期望R_AARCH64_ADR_PREL_PG_HI21用在 adrp 指令上，但你的编译器生成了R_AARCH64_ADR_PREL_LO21，那链接器解析出来的地址一定是错的。
实际的验证方法是分别编译出一组包含各种访存模型的目标文件，用readelf -r检查重定位类型是否和预期一致，再交给链接器做最终链接。链接失败时错误信息往往会指向某个“立即数越界”或“未知重定位类型”，这时不要急着在指令选择器里打补丁，先回到 ABI/ELF 文档里查一下该类型适用的指令和上下界。很多“看上去像编译 bug”的问题，其实是你对重定位类型的合法应用范围理解不全。
6. 安全与性能边界下的 ABI 再审视
写编译器后端，不能只做“能不能工作”的正确性验证，还要考虑安全属性和性能模型。ABI 会影响函数调用时的漏洞面，也会影响 CPU 分支预测和缓存访问的友好程度。这个视角在日常业务代码里很难被感知，但在系统软件、内核对接口、安全启动链上会变得极其重要。
6.1 寄存器清零与敏感数据残留
一个函数内部的局部变量通常保存在寄存器或栈帧里，函数返回后这些寄存器可能还残留着密钥、明文、用户口令等信息。ABI 并不要求函数在返回前把所有临时寄存器清零，这是调用者的自由。但从安全角度考虑，编译器可以在开启了安全选项时，支持在返回前对包含敏感数据的寄存器做清零。但这需要和调用约定一致：如果某一个寄存器是 callee-saved，编译器需要先恢复它原始的值，再去做清零；如果直接清零，会破坏调用者的预期。所以安全增强不能脱离 ABI 约束。
栈也很敏感。一个函数栈帧如果分配了 64 字节，但只写了前 32 字节，函数返回后这 64 字节中都可能有残留数据。后面另一个函数又分配到同一块栈区域时，可能无意间读到上一任函数的值。这在寻常 C 代码里不算 bug，但如果你打算在编译器层支持“栈初值清零”或“防止敏感数据残留”选项，就要在 ABI 允许的栈帧组织方式上灵活调整。否则单纯的“函数入口 memset 栈帧”不仅浪费，还可能覆盖已经由调用者写入的参数。
6.2 控制流完整性对间接跳转的要求
现代二进制安全方案会对间接跳转进行保护，例如在跳转前检查目标地址是否在一个允许集合中。AArch64 上通常会利用 PACIASP/AUTIASP 指令来签名和验证返回地址，这也和 ABI 有直接关系：如果编译器选择不使用帧指针，也不使用相关指令，那么异常返回时如果返回地址被破坏，程序很难自动感知。而 ABI 文档中会定义哪些指令序列在函数入口和返回路径上是合法的。
作为编译器后端，如果你想利用这类安全特性，可能需要在函数入口插入对返回地址做签名的指令，在返回前验证签名。这会改变函数整体的栈帧风格，也影响叶子函数判定。举个例子：一个叶子函数本来无需触碰 x30，但如果插入了 PACIASP，它同时也就改变了返回时的行为，叶子优化和分析都要重新检查。源码审计阶段如果只把 ABI 当成“寄存器搬运规则”，很容易忽略这些安全和编译器优化之间的耦合点。
6.3 高性能场景下的 ABI 优化空间
ABI 定义了默认行为，却不等于禁止实现更好的行为。编译器可以带着 ABI 约束去优化函数调用边界。例如，如果一个参数只在被调用者的某个基本块里使用，那么它不需要保存到栈，直接占用寄存器即可。如果 callee-saved 寄存器数量吃紧，编译器也可以选择把原本需要保存的寄存器重新分配成 caller-saved 寄存器，但前提是函数内部不再有新的 call，否则跨调用存活的值会被覆盖。
这类优化都会让生成代码和教科书里的 ABI 示例产生差异，但并不会违反 ABI。很多人误以为 ABI 合同意味着“整个函数只能有一幅标准画面”，其实不是。ABI 合同只约束二进制接口的可见面，内部怎么安排寄存器、怎么分配栈槽，只要在入口出口满足调用者的预期，都是优化的自由空间。
6.4 大端小端场景下的 ABI 差异
ARM 架构既支持小端也支持大端，但很多工具链实际只认真做过小端。在做源码审计时，大端是一个经常被忽略的测试维度。字节序变化会影响参数里“子寄存器字段”的提取，也会影响结构体成员从内存加载到寄存器后是否需要交换字节序。ABI 文档通常写成同时支持两种字节序，但后端代码在“小端路径正常，大端路径 bug”的情况很常见。
我的建议是，在准备后端测试矩阵时，至少留一台大端环境跑一遍全量 ABI 用例。抓到的 80% 问题往往不在复杂特性里，而是发生在从内存中读取结构体成员、从寄存器打包写入内存这类基础操作中。
7. 落地路上的最后一公里：测试、回归和文档联动
如果你已经在自研编译器里实现了前文提到的函数调用规则，下一步就要建立一个能长期回归的 ABI 测试套件。代码生成器很容易在某个优化改动里无意破坏调用约定，因为这种问题通常不会立刻导致测试失败，而是等到其他模块跑崩才暴露。下面是我建议的测试分层和联动手段。
7.1 单测层：指令模式的 Golden 测试
在后端单测里加入“Golden 汇编测试”，把参数类型、返回类型、寄存器压力等关键场景固定成小函数，预期文件里存放希望生成的汇编片段，任何代码改动后跑一遍 diff。这个层级能快速抓住诸如“某个 HFA 参数被错误地放进了 x0”的明显回归，但缺点是只能检验形状，不能验证真实运行时正确性。
单测场景要覆盖：
- 0 到 20 个整型参数的函数；
- 混合整型和浮点参数的函数；
- 返回 2 到 4 个双精度成员的结构体；
- 返回超过 16 字节的结构体；
- 叶子函数和非叶子函数的开启与返回；
- 使用 x29 帧指针和省略帧指针两种模式。
7.2 集成层：不同工具链互相调用的混编测试
集成测试应该采用双工具链混合链接的方式，这也是最能模拟真实场景的测试。用 Clang 编译主程序，用自研编译器生成一个或多个被调用函数，然后把它们链接到一起。同时做反向组合：用你的编译器编译主程序，调用 Clang/GCC 编出来的库函数。
我通常还会加一层“ABI 边界探针”函数，函数的功能就是输出当前寄存器中收到的参数值和栈上参数值。这样只要主程序传参合理，被调用函数就能打印出自己看到的值。两边的值一不一致很快就能看到。如果不对，再结合汇编定位是前 8 个参数的问题，还是栈上参数偏移的问题，比盲目改指令选择器要高效得多。
7.3 与规范仓库版本保持同步的审计节奏
ABI 规范不是完全静止的。新增指令集扩展、新增安全特性、新增语言标准时，都会对应修订规范仓库里的相关章节。因此“源码审计”不应当是一次性工作，而应该是持续性的。
我建议团队每隔几个迭代或版本计划前做一次规范仓库的 diff 检查。重点看官方变更描述和新增的测试用例。凡是有变更的章节，都要映射到后端代码的哪些部分受影响。比如新增了某个向量类型的状态保存规则，你需要检查寄存器保存列表里是否支持新的寄存器类别；新增了某个内存模型需求，你需要检查生成的原子操作指令序列是否还需要额外的屏障。
7.4 知识沉淀：把踩坑记录变成代码注释
最后，我强烈建议把审计过程中发现的“规范文档和直觉不一致”的点，写成注释放到后端代码旁边。比如“此处参数计数是从 x0 开始，而不是从 x1 开始”“第 9 个参数位于 sp+0，但需要先确保调用者已 16 字节对齐”“HFA 只适用于同类型浮点成员，向量类型不是 HFA”。这些注释不仅对后来的维护者有价值，也方便你在重新审视代码时快速回忆起当时的决策依据。
代码注释不必写成论文，但要有指针性：告诉读者“我在哪里见到这条规则”“为什么不按普通结构体处理”。这样一来，即使有新同事加入，也能沿着这些注释回到规范仓库去加深理解。工具链代码最容易产生“别人看不懂”的黑魔法，ABI 相关逻辑尤其如此。
我个人在实践中还有一个习惯：每解决一个 ABI 问题，就在测试套件里增加一个对应用例，并给用例起一个能追溯到问题根因的名字，比如stack_param_offset_with_alignment、hfca_return_v0_v1、sret_large_struct_x8。这类命名比test_abi_001有用得多。几个月后再跑测试时，看到名字就能知道它保护的是什么行为，而不是看到一个编号后还要去翻日志。
如果你正在为一个新架构做后端，或者想把一套老旧工具链迁移到新的 ABI 规则上，最值得投入的就是“规范到代码的映射表”和“混编测试套件”。前者决定方向，后者保证不跑偏。其他所有工作，比如文档翻译、指令时序优化、栈帧加密，都可以在此之后慢慢补齐。谨记一点：ABI 是合同，不是风格建议。所有想当然的“这样应该也行”，最终都会在混编调试时变成一场灾难。
