干编译器后端这行的早晚都会栽在 ABI 手里。不是参数传错了寄存器导致崩溃就是结构体布局对不上系统库的偏移再不然就是写好的内联汇编跟 C 函数互相调用时现场翻车。这些问题追根溯源指向的都是同一个东西——Arm-abi-aa一套由 Arm 官方维护、用来定义 ARM 与 AArch64 指令集二进制接口的规范仓库。这篇东西不是泛泛讲概念而是把仓库结构、核心规范条文、编译器后端的对接路径全部摊开做一次源码级的评审和落地复盘。想写编译器后端、维护交叉工具链、或者排查底层二进制兼容问题的朋友读完应该能少走不少弯路。1. 全景拆解Arm-abi-aa 仓库到底装了什么1.1 一个 ABI 规范仓库凭什么值得源码级审计先回答一个问题ABI 到底是什么很多人把它跟 API 混着说其实完全是两码事。API 是源代码层面的约定函数叫什么名、传什么参数、返回什么类型写代码的时候就能看到ABI 是二进制层面的约定编译完之后函数参数放在哪个寄存器、结构体成员偏移多少字节、栈指针怎么对齐、异常信息怎么展开这些看不见摸不着的东西才是程序能不能跑起来的关键。你可以把 ABI 想象成两台机器之间的齿轮咬合规则。编译器前端把 C 源码翻译成中间表示后端再把它变成指令但最终产出的机器码必须按照一套统一的规则来使用寄存器、栈和内存不然两个函数之间互相调用的时候A 函数把参数放在 R0B 函数却以为参数在 R1结果必然是一团糟。更隐蔽的是结构体布局系统库 printf、malloc 这些函数编译时是按某个固定偏移访问结构体成员的你这边编译器如果对同一结构体算出了不同的布局哪怕只差一两个字节就是用户态直接踩内存或者被 heap 破坏的问题。所以 Arm 官方把 ABI 规范整理成一个公共仓库开放给全世界所有工具链实现方审核和参考这件事的意义比表面看上去大得多。它意味着 GCC、LLVM、各种商业编译器的作者对参数到底怎么传这种问题有一个统一的标准答案而不是各家自己在评论区吵架。源码级审计就是把这些规则一条条抠出来对照自己项目的实现检查一致性。1.2 仓库文档地图与阅读优先级Arm-software/abi-aa 这个仓库文档是按主题拆开的每份文档管一块。我按实际开发中遇到的频率给你排个优先级。最高优先级是 AAPCS全称 Procedure Call Standard for the Arm Architecture分 aapcs32 和 aapcs64 两份。这俩管的就是函数调用约定参数放哪些寄存器、返回值怎么给、谁负责清理栈、栈对齐要求是多少。你做编译器后端第一件事就是把这两份文档吃透因为代码生成和寄存器分配全部围绕它们展开。第二梯队是 ELF 相关规范aaelf32 和 aaelf64。这两份文档定义了目标文件格式、重定位类型、动态符号表、GOT/PLT 机制。如果只是生成一个静态的可执行文件接触得少一旦涉及动态链接、做链接器、或者让编译器生成的代码能被别的运行时加载就必须看。第三梯队是 C 与异常处理相关cppabi 和 ehabi。cppabi 是关于 C 名字修饰、RTTI、虚表布局的格式约定ehabi 是 ARM32 专用的异常展开格式。做 C 编译器或者需要支持 C 异常的语言这两个绕不开。最后是 rtabi 和各个扩展特性的文档。rtabi 描述运行时 ABI比如 C 库如何与内核交互扩展文档则涵盖 SVE、SME、BF16 这些新指令集特性对 ABI 的影响。这些通常是在已有编译器之上加指令支持时才看。不同角色的阅读路径也不同。要是只做纯汇编开发或者嵌入式裸机程序看 AAPCS 的一半就够用了要是维护 Linux 系统上的工具链ELF 和动态链接相关也跑不掉要是做 SDK 分发C ABI 兼容性就必须盯紧。1.3 怎么把一个 ABI 文档读出门道读这些规范文档跟看书不太一样。它不是让你从头到尾背下来而是要带着问题去找答案。我自己的习惯是三步走先看版本号和历史修订记录确认是不是你要对齐的版本——AArch64 的 AAPCS 经历过多轮更新不同版本对复合类型传参会略有差异再看规范性条款文档里凡是出现 must、shall、shall not 这些词的地方都是硬性要求出现 should 的则是建议最后重点看 pseudocode就是文档里用伪代码描述的算法逻辑。比如 aapcs64 里描述参数分类时有一段很长的伪代码定义了怎么判断一个参数是整数类、浮点类、HFA同构浮点聚合类型还是其他复合类型。这段伪代码的严谨性非常高最接近一门小语言的风格是真正的源码级描述。建议你直接把它翻译成测试用例变成 C 语言或者 Python 脚本喂给编译器跑比对着文档发呆高效多了。2. 核心规范逐条啃AAPCS 与参数传递的真谛2.1 AAPCS6464 位世界的调用约定AArch64 的 AAPCS 是开发者接触最多的一份规范寄存器分配规则清晰、惩罚分明。基本框架是这样的X0 到 X7 共八个通用寄存器负责整数、指针参数浮点和向量参数走 V0 到 V7 八个向量寄存器返回时整数走 X0浮点走 V0。特殊寄存器里X8 用来传大结构体返回地址X30 是链接寄存器保存函数返回地址SP 要求 16 字节对齐。这里面的规则虽然多但逻辑性很强。比如被调用者保存寄存器是 X19 到 X28这一组寄存器在进入函数之后如果要用必须先压栈保存退出前恢复。V0 到 V31 里的 V8 到 V15 也有类似规定但只要求低 64 位也就是 D8 到 D15被调用者保存。这个设计不是拍脑袋定的它保证了调用者不需要在每次调用前保存一大堆浮点寄存器函数内部又能有足够的临时浮点寄存器使用。实际写后端的时候最容易被坑的是参数寄存器分配不是简单的用完 X0 用 X1。规范里引入了 NCRN下一个通用寄存器编号、NVRN下一个向量寄存器编号和 NSAA下一个栈参数地址三个状态量本质上是说每个参数来了先分类再按分类去消耗对应资源。整数参数就更新 NCRN浮点参数就更新 NVRN而一个参数太大进不了寄存器的时候NSAA 开始接管按 8 字节对齐往栈上排。变参函数是另一个容易踩的坑。像 printf 这种不定长参数函数规范要求所有参数都用通用寄存器传递不享用浮点寄存器传参的待遇。为什么这样因为变参函数在被调用时没法预知参数的真正类型如果参数前一半走浮点寄存器后一半走整数寄存器接收方根本不知道去哪里取。所以规范干脆一刀切浮点参数也要先转成通用寄存器再传递。2.2 HFA 与结构体传参最容易实现错的一段AAPCS64 里最有代表性、也最考验后端实现精度的是 HFA 规则。HFA 是 Homogeneous Floating-point Aggregate指一个结构体或联合体里有 1 到 4 个成员且成员类型完全相同的浮点类型。比如 struct { float a; float b; } 这种就是一个二成员 HFA传参时可以整体占用两个浮点寄存器 V0 和 V1。但要小心结构体里字段顺序、嵌套、联合体这些都会影响它是不是 HFA。像 struct { float a; int b; } 就不是 HFA因为成员类型不统一这时候它会被当作普通复合类型处理如果大小不超过 16 字节会分解成多个 64 位块能用通用寄存器就用通用寄存器不能就上栈。而超过 16 字节的复合类型则通过 X8 寄存器传递指向内存的地址。这套规则扩展到向量类型上就变成 HVAHomogeneous Short-Vector AggregateNEON 的一些向量类型就是典型例子。ARM 在 SVE 时代又对可扩展向量类型的传参做了专门定义因为 SVE 的向量长度是编译时不确定的没法像 NEON 那样按固定 128 位去拆所以规范单独给出了 SVE 参数传递规则。光看文字描述容易晕我建议动手做实验。写一个很小的 C 文件定义一个函数接受上面那种混合结构体参数再用 clang -target aarch64-linux-gnu -S 编译观察汇编代码马上就能理解结构体是怎么被拆成多个传入单元的。这个实验做完你对 AAPCS64 复合类型传参的理解会比读十遍文档都管用。2.3 AAPCS3232 位世界的经典规则AArch32 的 AAPCS 和 64 位版本思路一致但寄存器资源不同规则细节差别很大。32 位下参数寄存器和被调用者保存寄存器的分工是R0 到 R3 传参数和返回值R4 到 R11 由被调用者保存R12 是内部过程调用临时寄存器又被称为 IPR13 是栈指针 SPR14 是链接寄存器 LRR15 是程序计数器 PC。栈对齐要求是 8 字节比 AArch64 的 16 字节宽松一半。浮点参数在 32 位下用的是 VFP 寄存器s0 到 s15或者 d0 到 d7 成对使用负责传浮点参数。在硬浮点 ABI 里浮点参数直接进 VFP 寄存器软浮点 ABI 则会把浮点参数换成整数表示放进通用寄存器。这两者之间的差别直接决定了编译出来的二进制能否与链接库互换。做嵌入式开发的都知道ARM 和 Thumb 代码互相调用时必须遵循同一个 AAPCS寄存器使用规则是统一的否则跳转过去必炸。32 位下还有几个老生常谈的细节比如混合使用 ARM 指令集和 Thumb 指令集时函数的地址的 bit0 会作为状态标志使用——调用一个奇数地址的函数会让处理器切换到 Thumb 模式。这个问题在写内联汇编或者 dlsym 取函数地址时特别容易踩取出来的地址必须按实际指令集去解析。3. 源码审计方法论如何从规范仓库提取真经3.1 把仓库历史和 issue 当成金矿来挖很多人读开源仓库只看主分支的最新版本这个习惯在审计 ABI 规范时是远远不够的。ABI 的本质是兼容性承诺破坏兼容性不是一拍脑袋就能决定的所以很多重要规则的背景、争议和修订过程恰恰藏在 git log 和 issue 讨论里。Arm-abi-aa 这个仓库每个版本的变更都会附上勘误说明这些说明不会一定写进正式文档但它们往往解释了为什么要改可能是发现了某个边界 case 会导致两个编译器生成不同布局也可能是某家操作系统厂商在适配过程中发现原有规则没法满足需求。对审计者来说这些信息价值极高——你不仅能知道现在是什么规则还能知道过去哪里出过问题为什么现在要这样定。我自己的习惯是在做一次交叉工具链适配之前先拉一遍仓库的 release 列表列出所有与目标架构相关的版本变更然后追踪这些变更对应的提交和 issue。比如 AArch64 的 AAPCS 对复合类型传参有过几次优化比如避免不合理的寄存器立即上栈这类行为你如果不了解这些演进直接对着最新版本实现可能在旧系统的链路里遇到诡异的二进制兼容问题。3.2 从规范到实现LLVM 后端怎么落地 ABI有了规范条文接下来就是看真正的编译器项目怎么落实。LLVM 的 AArch64 后端是个非常好的研究对象它的代码组织很干净调用约定描述集中在 AArch64CallingConvention.td 文件里。这个文件用 TableGen 描述了寄存器分配顺序、参数分类条件、栈上对齐规则编译器在 SelectionDAG 阶段会读取这些描述自动完成参数类型到物理寄存器的映射。LLVM 里做 ABI 落地不是纯手写 if-else而是高度声明式的。后端开发者通过 CCIfType、CCIfNotVarArg、CCAssignToReg、CCAssignToStack 这些描述条目一条条声明遇到什么类型匹配什么条件执行什么动作。比如浮点参数在非变参函数里被分配到 V0 到 V7在变参函数里则用通用寄存器替代就是通过一组 CCIfNotVarArg 和 CCIfType 组合描述实现的。真正处理结构体传参时LLVM 会在类型降级阶段把复合类型拆分成多个基本类型每个拆分后的参数再走一遍上面的调用约定匹配流程。这个过程叫 legalization也是新手最容易迷茫的地方你以为编译器直接把整个结构体塞进一个寄存器实际上它会把结构体成员铺开变成多个虚拟寄存器再按 ABI 规则一个萝卜一个坑地安排物理位置。看 LLVM 源码时我建议顺着 LowerFormalArguments 和 LowerCall 这两个函数往下读。前者处理函数入口如何从调用约定规定的寄存器/栈位置取出参数后者处理调用方如何按同样规则把参数摆好。这两个函数一个在函数入口、一个在函数出口就像收发两端的密码本必须严格一致。3.3 从规范到实现GCC 后端的对照审计GCC 的 ARM 与 AArch64 后端是另一个值得对照学习的实现。它的实现大量集中在 aarch64.cc 和 arm.cc 这两个大文件里核心数据结构是 CUMULATIVE_ARGS你可以理解为一个参数分配游标每处理一个参数就更新一次里面的计数。GCC 的状态机设计比 LLVM 的声明式描述更有命令式风格初看会觉得处理逻辑藏得很深。GCC 和 LLVM 对同一份 AAPCS 规范的实现绝大多数情况下是等价的因为两者都严格对照规范伪代码。但如果你把两个编译器生成的汇编放在一起逐行对比会发现一些细节差异比如某些整数参数是直接进入寄存器还是先经过栈上的影子存储某些复合类型在寄存器还够用时是拆开放还是宁可统一走栈。这些差异大多数不违反规范但反过来提醒我们对 ABI 兼容性要求极高的场景不能假设规范一样行为一定一样最好用自动化差异测试验证过再下结论。对照审计的时候我的习惯是挑一个具体的 ABI 特征比如四字段整数结构体作为参数如何传递在 GCC 和 LLVM 里分别搜索对应的处理逻辑然后再写一个小函数编译验证。这样三管齐下——规范条文、编译器源码、实际汇编输出——效率是最高的。4. 编译器开发落地从 ABI 规则到机器码生成4.1 建立参考基线让现成工具链当你的老师自己动手写编译器后端最忌讳的是闭门造车明明能用一套成熟工具链做行为基准非要从零开始硬猜规则。我一开始踩过这种坑对着 AAPCS64 文档把参数传递规则写完之后自认为天衣无缝结果一个简单的递归调用测试就跑出了栈指针不对齐的崩溃。后来冷静下来其实解决方法很简单就是先让 clang 把目标源码编译成汇编逐条对照它的 prologue、参数传递和栈帧布局马上就能定位到我的实现哪里跟规范不一致。这个思路可以放大成一个完整的开发方法手头同时准备 clang 和 gcc 两个参考编译器写一组覆盖各种参数类型的 C 测试用例让它们分别编译再反汇编对比输出。你会发现很多规范没写死的灰色地带不同工具链有自己的选择你的后端要做的是在这些选择中确定一种并且保证与生态其余部分兼容。参考基线的另一个作用是快速生成测试期望值。很多编译器测试框架里都支持 golden file 测试把参考工具链的输出作为期望结果你自己的后端实现只要输出与期望一致就算通过。这个方法在早期开发阶段价值巨大能让你在功能还不完整时就建立起回归保障。4.2 最小可行性后端AArch64 ABI 的初级阶段如果你的目标是给某种语言写 AArch64 后端我建议分四个阶段推进 ABI 支持每阶段都有明确的可验证目标。第一阶段只支持整数参数。写一个函数参数是两个 long返回它们的和编译出来应该看到 X0 和 X1 被作为参数输入结果放在 X0 返回。这个阶段重点验证参数序号的映射、返回值的放置、叶子函数的 prologue 是否为零成本。第二阶段加入浮点参数和返回值。写一个 double 加法函数验证 V0 到 V7 的参数映射以及 V0 的返回值放置。同时要处理浮点寄存器的保存与恢复策略函数里用到了哪些浮点寄存器哪些需要调用者保存哪些需要被调用者保存。第三阶段处理 HFA 和复合类型。这是工程量大的一步需要实现结构体拆解逻辑。先处理四成员以内的浮点结构体再处理普通小结构体最后处理大结构体的 X8 传地址路径。每一步都要用结构体测试用例严格验证。第四阶段才轮到变参函数和栈对齐异常路径。变参要处理参数在寄存器上的一次性倒腾栈对齐要确保每个调用点 SP 都是 16 字节整数倍。这两个功能是排查信号最隐蔽的部分放到最后做前面的基础验证也会更方便定位问题。4.3 验证清单哪些测试用例必须覆盖我自己维护的 ABI 验证清单经历了从三四个用例膨胀到上百个用例的过程选几个最有代表性的分享。整数与浮点混排参数用例func(float a, int b, float c, int d)重点观察 AAPCS64 中 NCRN 与 NVRN 的交叉推进。很多人误以为参数寄存器会按类型分区连续使用其实整数和浮点是两套资源独立消耗的实际组合方式由参数顺序决定。大小结构体边界用例分别定义 8 字节、16 字节、17 字节、32 字节的结构体作为参数观察它们分别进入整数寄存器、混合寄存器与内存。尤其是 17 字节这种临界值最容易在实现时出现偏移错误。可寻址返回值用例定义一个返回 24 字节结构体的函数观察编译器是否自动分配一块内存并把地址放入 X8然后在调用方把返回值从该内存拷贝到目标位置。这个场景考察的不仅是传参还有临时变量生命周期管理。变参与栈恢复用例写一个绕了一圈的 printf 封装内部用一个 va_list 遍历所有参数重点确认所有参数都按整数寄存器传递且函数退出后栈指针完全恢复。这些用例不一定都能一次跑通但它们每一个都精确命中 ABI 实现中的某个独立风险点组合起来就是一张有效的回归网。5. 实战避坑ABI 落地中的典型问题与长久排查5.1 结构体偏移与 padding无声的二进制杀手ABI 落地里最隐蔽的问题不是寄存器分配而是结构体布局中的隐式填充。C 语言允许编译器在结构体成员之间插入 padding以满足每个成员的自然对齐要求。比如 struct { char a; int b; }; 在 AArch64 下a 占 1 字节随后编译器会填充 3 字节b 从偏移 4 开始整个结构体大小是 8 字节。如果你在后端实现时没有正确计算对齐返回结构体大小的结果就会偏小后续的栈帧布局和参数传递全都会错位。这个问题在做外部函数接口FFI时尤其要命。你的语言如果支持调用 C 库函数那你必须能精确认出 C 语言结构体的每个成员偏移。一个常见的做法是直接用 Clang 的 record layout 信息来做绑定如果自己手写布局计算一定要把位域、union 和显式对齐属性都考虑进去。我的建议是在处理结构体布局时写一套独立的布局模块不要跟参数传递逻辑混在一起。布局模块保证对于一个给定的类型它的大小和对齐是多少参数传递模块依赖这个结果做寄存器/栈分配。两个模块分开测试各自正确了组合起来才能稳定。5.2 栈对齐与栈帧布局一个字节都不能差AArch64 的 16 字节栈对齐要求是绝对的任何违反都会导致问题——有些在带浮点指令时会触发 SIGBUS有些则在使用某些系统调用时静默出错。为什么一定要 16 字节因为很多存储指令和某些操作系统内核的代码路径假设栈指针是 16 字节对齐的你破坏了它等于破坏了这条链路上所有下游代码的假设。栈帧布局时被调用者保存寄存器的压栈顺序也值得注意。虽然 AAPCS 没有硬性规定压栈顺序但不同工具链的排列会影响调试信息的展示和栈回溯对整个生态的一致性有影响。我建议严格参考 clang 的输出顺序来实现这样用 gdb 或者 perf 分析混合编译的二进制时栈回溯的准确性会更好。另外如果在实现里支持了可变参数函数堆栈清理要格外小心。ARM64 上变参函数的参数可能在栈上也有拷贝函数返回前必须确保 SP 恢复到入口时的值否则返回地址取错整个调用就变成一场灾难。5.3 混合 ABI 与指令集切换兼容性的大熔炉实际的嵌入式工程里一个系统里面常常混着多种 ABI 风格。比如一个固件里既有 ARM 32 位代码又有 Thumb 代码甚至在一些异构 SoC 上还有 AArch32 和 AArch64 并存的情况。编译器后端如果生成的是纯 ARM 指令而某个回调函数指针是 Thumb 地址直接跳转就会导致指令译码错误处理器把 Thumb 模块当 ARM 执行第一条指令就崩。处理混合 ABI关键是对地址低位标志的感知。ARM 架构用地址 bit0 表示目标函数是否属于 Thumb 模式奇数地址表示 Thumb偶数地址表示 ARM。编译器在生成函数指针调用时必须根据目标函数实际的指令集正确设置这个低位。动态链接场景中PLT 机制也会根据符号类型选择跳转方式这个逻辑如果没处理对dlsym 取得的函数地址就可能直接被当成纯地址调用。我做这类适配的经验是在编译器后端增加一个统一的函数指针描述数据结构把纯地址、指令集类型、是否全局入口这些信息打包管理调用和返回统一走这一个函数处理。这样每次遇到 ARM/Thumb 切换、AArch32/AArch64 衔接的地方逻辑都汇聚到一个入口排查问题的时候思路会清晰得多。通常我们把 ABI 当作一种底层细节可在实际开发中ABI 就是你编译器和整个系统之间的全部契约。我个人的体会是做后端开发最值得的投资就是把 aapcs64 和 aapcs32 这两份规范的核心伪代码逐行啃透然后立刻翻译成测试用例。规范文本是静态的测试用例却是活的守护者。每实现一个新特性就回头跑一遍这一组回归测试只要它们绿着你在 ABI 层面就没有欠下新的技术债。以后再遇到那些看似毫无来由的函数崩溃或结构体错位你就可以底气十足地告诉伙伴先检查 ABI大概率问题就藏在这里面。
