这篇内容不是给你念 ARM 的 Datasheet也不是整理一份“AArch64 指令大全”。我想聊的是arm-abi-aa这套源码仓库背后的设计逻辑以及一个做编译器落地的人该怎么去读它、审它并且真正把它用到自己的工具链开发里。先说清楚这是什么。arm-abi-aa是 ARM 官方维护的 ABI 规范仓库里面存的不只是 AAPCS64 那一份 PDF而是一整套与 AArch64/AArch32 调用约定、数据类型、重定位模型、异常展开、DWARF 调试信息相关的文档和定义。它决定了你的 C 函数怎么传参、结构体怎么对齐、汇编器怎么生成重定位、链接器怎么解析符号甚至连调试器怎么恢复栈帧都跟它有关系。作为一个常年跟编译器后端打交道的人我的建议是不要把它当成“参考手册”去翻要当成“源码”去审。这个仓库里的每一条规范背后都有对应的 LLVM/GCC 实现、binutils 处理逻辑和实际硬件行为。这篇文章我会从整体架构、审计路线、核心细节、编译器落地几个维度拆开讲最后再给你一份我平时排查 ABI 相关问题时的实操笔记。1. Arm-abi-aa 全景拆解这套仓库到底管了哪些事1.1 从 AAPCS 到 arm-abi-aa为什么说“ABI 仓库”不等于“一份 PDF”很多人对 AAPCSProcedure Call Standard for the ARM Architecture的印象停留在“32 位时代的传参规则”但arm-abi-aa仓库里的内容远不止这些。它把 ARM 架构的 ABI 拆成了多个维度分别用独立的文档或源码模块维护。我列一下核心组成你在仓库根目录基本都能找到对应目录或文件AAPCS64AArch64 架构的过程调用标准这是最核心的一份定义了参数寄存器、栈帧布局、结构体传递规则。AAPCS32AArch32也就是 ARMv7 及之前的过程调用标准和 AAPCS64 有不少差异。ABI for the C LanguageC 语言层面的 ABI包括基本数据类型的大小、对齐方式、枚举类型映射等。ELF ABI for the ARM ArchitectureELF 文件格式在 ARM 上的具体要求包含重定位类型定义、节区命名规则、属性节区等。ABI for DWARF调试信息格式在 ARM 上的约束涉及 DWARF 寄存器编号映射、CFI 规则等。Exception Handling ABI异常展开unwinding相关的 ABI 规范AArch64 上用的.eh_frame和旧式 ARM 的EXIDX都在这里定义。这个仓库存在的意义是它不光是给读书人看的规范更是给工具链实现者对照的“契约”。LLVM 后端在实现调用约定时不是自己拍脑袋设计而是直接对照 AAPCS64 的条款来实现。同样binutils 里readelf解析重定位条目时也是按照 ELF ABI 文档里的定义去解码的。1.2 版本演进与仓库里的“时间线”我在审计这个仓库时注意到一个很关键的问题ABI 是分版本演进的而且不同版本的 GCC/LLVM 可能实现了不同版本的 ABI。仓库里会保留历史版本的规范文档或者在一个文档里通过修订记录标注变化点。比如 AArch64 的 AAPCS 就有过关于 SVE可扩展向量扩展和 SME可扩展矩阵扩展的补充规范这些后来都被合入了主文档或新增了独立章节。用实际例子说明早期 AAPCS64 对va_list的定义是一个指向参数栈区域的指针但后来 ARM 引入了“参数在寄存器中传递时va_list也要能访问到寄存器中的值”的规则于是va_list变成了一个结构体里面包含了__stack、__gr_top、__vr_top、__gr_offs、__vr_offs等字段。如果你用的编译器版本和库文件版本不一致解析可变参数时就可能出现完全不符合预期的地址这正是 ABI 版本错配的典型坑。注意读这种仓库第一步不是去背条款而是先看清这个仓库的“版本-硬件特性-编译器实现”三者的对应关系。我一般会在仓库里先搜SVE、SME、PAuth指针认证、MTE内存标记扩展这些关键词确认目标平台开启的特性再决定用哪套 ABI 规则去约束自己的代码生成。2. 源码审计路线图先建“ABI→实现”映射再逐层下钻2.1 审计前需要建立的全局视图如果你直接打开 arm-abi-aa 仓库一篇篇读大概率会陷入细节出不来。我建议你先把整个仓库当成一份源码项目的根目录然后建立一张映射表把“规范文档的哪个小节”对应到“LLVM/GCC 的哪个文件哪个函数”。这样审计时才有抓手而不是漫无目的地浏览。我自己的映射思路大概是这样的ABI 主题规范文档位置LLVM 侧关键文件binutils 侧关键工具整型/指针参数传递AAPCS64Procedure Call StandardAArch64ISelLowering.cpp里LowerFormalArguments、LowerCallllvm-readobj查看生成的 reloc浮点/向量参数传递AAPCS64 中VFP相关小节AArch64ISelLowering.cpp的CC_AArch64相关代码readelf -A查看属性结构体返回AAPCS64 里Composite Types小节AArch64TargetLowering中CC_AArch64处理sret的逻辑objdump -d观察调用点栈对齐AAPCS64 的Stack ConstraintsAArch64FrameLowering.cpp中emitPrologue、emitEpilogueobjdump -d检查sub sp, sp, #Nva_listAAPCS64的Variadic实现AArch64ISelLowering.cpp中LowerVAARG、LowerVASTART观察va_arg展开前后的地址计算重定位ELF ABI 章节ELFObjectWriter.cpp中的重定位类型发射readelf -r查看.rela.*条目这张表的作用不是让你背下来而是给你一个审计起点。你读规范时遇到一条规则就要问自己这条规则在 LLVM 的哪个函数里体现我能不能用readelf或者objdump造一个反例来验证2.2 审计的四个核心模块我一般把审计分成四条线每条线都对应一个独立的 ABI 关注点第一条线调用约定Calling Convention。这是最高频的 ABI 场景。目标很明确AArch64 下整数、指针、浮点、向量参数各走哪些寄存器超出部分怎么压栈结构体怎么拆分。审计重点是x0-x7和v0-v7的分配规则以及x8这个“间接结果寄存器”的处理。第二条线内存布局与数据模型。C 语言的char、short、int、long、指针在 AArch64 下分别是多少位、多少字节对齐long double到底是 16 字节 IEEE 754 还是 128 位扩展精度这些直接决定结构体大小和偏移一旦和库文件不一致轻则数据错位重则直接越界。第三条线重定位模型。AArch64 有大量与位置无关代码PIC相关的重定位类型比如R_AARCH64_ADR_PREL_PG_HI21负责计算某个符号所在页的地址配合R_AARCH64_ADD_ABS_LO12_NC形成页内偏移。审计时要注意不同重定位类型的语义以及编译器在什么场景下会使用GOT全局偏移表。第四条线异常展开与调试信息。AArch64 使用.eh_frame来记录栈展开规则DWARF CFI 指令会被编码到.eh_frame里。审计时重点看栈指针、帧指针的恢复规则以及RA_SIGN_STATE这种和指针认证相关的伪寄存器怎么处理。2.3 审什么、怎么审具体操作步骤我这里给出一个可复制的审计流程如果你没有太多经验直接按这个流程走就行拉取仓库把arm-abi-aa仓库克隆到本地同时准备一份 LLVM 源码和一个 AArch64 的交叉编译工具链。选择切入点从一个简单的 C 函数开始比如int add(int a, int b) { return a b; }编译成汇编。翻阅对应规范打开 AAPCS64 文档找到整数参数传递部分确认a放w0、b放w1、返回值放w0。对照实现在 LLVM 源码里搜索AArch64ISelLowering.cpp找到LowerFormalArguments看它是怎么根据CC_AArch64分配寄存器的。造反例验证改掉某个参数的类型或顺序比如把int改成double观察寄存器分配的变化再回到规范里找对应条款。这套流程走完你对一个模块的 ABI 理解会比单纯读十遍文档都深。因为你在“规范→实现→结果”三者之间建立了一条完整的验证链路。3. 核心 ABI 细节深挖调用约定、数据模型与重定位模型3.1 调用约定里最容易被忽略的“规则优先级”AAPCS64 对参数传递的规则写得比较细但初学者很容易只记住“前 8 个整型参数用 x0-x7”却忽略了两个关键点一是参数类型和数量共同决定寄存器分配。比如函数void f(double a, int b, float c)在 AArch64 里a走d0b走w1c走s2它们各自有独立的编号空间。这里并不是把整型和浮点混在一起统编的浮点用浮点寄存器序列整型用整型寄存器序列。审计时要特别留意因为写后端时最容易在这类“双轨分配”上出错。二是结构体的“奇异”传递规则。AAPCS64 规定如果一个结构体的大小是 1、2、4、8、16 字节且成员都是“单一基本数据类型组合”它可能被当作一个“基本数据类型”来传递。比如struct { int a; float b; }这个 8 字节结构体在double寄存器里按一个 64 位值传递但如果结构体里有超过 16 字节的数组或者成员对齐要求变高就会退化为“内存传递”——通过隐式指针传参。这里有一个典型的坑我在审计时见过一个案例两个团队分别编译同一个函数接口一边用 GCC 编译一边用 Clang 编译双方对同一个结构体的传递方式产生了分歧。原因是该结构体大小是 24 字节按照 AAPCS64 应该走内存传递但其中一边的头文件里结构体定义不对导致编译器认为它只有 16 字节于是按寄存器传。结果就是两边函数调用约定不一致运行起来直接拿到垃圾参数。3.2 AArch64 的数据模型和栈布局到底怎么算AArch64 下常用数据模型是 LP64也就是long和指针都是 64 位int是 32 位。这看起来没什么好讲的但配合栈对齐规则就有意思了。AAPCS64 要求在执行函数调用之前栈指针必须 16 字节对齐。也就是说在一个函数入口sp是 16 字节对齐的调用下一个函数之前当前函数需要保证sp减去参数区和局部变量区后仍然 16 字节对齐。这听起来简单但要做对编译器必须综合考虑参数压栈数量、局部变量大小、帧指针是否使用等多种因素。我来算一个实际例子假设一个函数有两个局部变量一个int4 字节、一个double8 字节同时它还要调用子函数子函数有 2 个栈传参数各 8 字节那么当前函数可能会在序言里执行类似sub sp, sp, #32的操作。这 32 字节怎么来的参数区 16 字节、局部变量可能要 16 字节为了对齐8 字节变量往往要额外垫 8 字节来满足 16 对齐。如果你手写汇编算错一位调用子函数时栈不对齐碰到用对齐指令如ldp/stp的场景就会崩溃。实操心得碰到栈对齐问题不要去猜直接用objdump -d看生成的指令或者用readelf -wf看.eh_frame里的 CFI 规则里面记录了函数出入口栈指针的变化量。这个比看多少文档都直观。3.3 重定位模型PIC、GOT 与页寻址的联动AArch64 的指令长度固定 32 位所以一条adrp指令只能编码一个 21 位的页偏移page offset配合 12 位的页内立即数偏移总共可以寻址 4GB 范围。这个设计决定了它在生成位置无关代码时经常需要两条指令配合来引用一个全局变量adrp x0, symbolPAGE add x0, x0, symbolPAGEOFFPAGE和PAGEOFF对应的重定位类型分别是R_AARCH64_ADR_PREL_PG_HI21有的实现也叫ADR_PREL_PG_HI21和R_AARCH64_ADD_ABS_LO12_NC。在审计 ELF ABI 文档时你要特别关注这些重定位类型的计算方式它们算的是符号所在页和当前指令所在页的偏移而不是符号本身的绝对地址。再往深一层如果要支持动态链接全局变量可能要走 GOT。这时编译器生成的是adrp x0, :got:variable然后ldr x0, [x0, #:got_lo12:variable]最终通过 GOT 表项拿到变量的真实地址。AArch64 的:got:重定位类型在 LLVM 和 binutils 里都有实现但细节差别要注意GOT 条目大小、对齐方式、是否使用LD64_GOT_LO12_NC等都会影响最终链接结果。我在审计 binutils 的readelf -r输出时会特别关注.rela.plt和.rela.dyn里的条目观察哪些是JUMP_SLOT、哪些是GLOB_DAT、哪些是RELATIVE。因为这几个类型的处理方式在动态链接器里不同JUMP_SLOT用于函数地址解析GLOB_DAT用于数据地址解析RELATIVE用于基于加载基址的重定位。这类问题在交叉编译场景下特别容易踩坑尤其是你自己写链接脚本或者做裸机/RTOS 启动代码时处理错一个重定位类型程序加载后访问的地址就是错的。提示如果你在排查一个“在可执行文件里正常在共享库里崩溃”的问题第一反应应该是去看重定位是否发生了变化而不是去怀疑代码逻辑。把.so里符号的地址分布和.rela.dyn对齐往往能快速锁定问题范围。4. 从 ABI 规范到编译器后端在 LLVM 里落地的完整路径4.1 找对入口文件AArch64 后端的关键代码地图如果说 arm-abi-aa 是“契约”那么 LLVM 的 AArch64 后端就是“实现”。你要做编译器开发落地必须清楚地知道契约的每一条在代码里的形状。我给出几个你一定会用到的文件AArch64ISelLowering.cpp这是指令选择层里最核心的文件LowerFormalArguments负责处理函数入口的参数LowerCall负责处理调用点的参数准备LowerVAARG处理va_arg。AArch64CallingConvention.td这个 TableGen 文件定义了多个调用约定比如CC_AArch64_AAPCS、CC_AArch64_Darwin、CC_AArch64_Apple等。改调用约定通常从这里开始。AArch64FrameLowering.cpp栈帧布局和序言/尾声指令的生成在这里栈对齐、帧指针、叶函数优化都在这处理。AArch64Subtarget.cpp特性开关在这里定义比如是否支持 SVE、是否支持 PAuth这些特性会直接影响 ABI 的某些分支处理。有一个比较实用的经验如果你想快速验证“某个参数类型在 AAPCS64 里到底怎么传”不用去翻文档熬时间直接在 LLVM 源码里跑一个小实验。写一个 C 函数编译成 LLVM IR然后用llc指定 AArch64 后端强制输出汇编观察x0-x7、v0-v7和栈的使用同时和AArch64CallingConvention.td里的规则对照。4.2 调试后端时的常用手段从 IR 到汇编的逐步下钻LLVM 后端调试有一个很顺手的流程我基本每天都会用先写好 C 源文件用clang --targetaarch64-linux-gnu -S直接出汇编快速确认 ABI 层面没问题。再用clang --targetaarch64-linux-gnu -O0 -emit-llvm生成 IR手动或自动进行指令选择。想看 SelectionDAG 阶段的信息用llc -view-dag-combine1-dags之类的选项可以图形化观察 DAG 变化但如果没有图形界面就用-debug-onlyisel打印日志。想看最终指令和寄存器分配用llc -stop-aftermachine-cp之类的参数控制编译阶段逐步观察。这套流程对我来说最大的价值是它把“ABI 规范”和“编译器生成结果”真正串起来。比如你想知道 AAPCS64 对 16 字节结构体传参的规则直接写一个 16 字节结构体的函数从 IR 往下跟看到CC_AArch64_AAPCS如何把它拆到两个 64 位寄存器里比读条文要直观得多。4.3 落地时最容易出错的三个点寄存器保存、可变参数、尾调用寄存器保存策略。AArch64 下x19-x28是被调用者保存的x9-x15是临时寄存器x16、x17是 intra-procedure-call 临时寄存器。后端在生成函数序言时要决定哪些被调用者保存的寄存器需要压栈分析每个函数实际用到了哪些。如果分析错了比如少保存了一个寄存器函数返回后调用者的局部变量被破坏这类 bug 极其隐蔽因为它只在特定代码路径下才出现。可变参数。C 数va_list在 AArch64 上是一个结构体里面记录了通用寄存器区、浮点寄存器区、栈区的当前状态。LLVM 后端在LowerVASTART里要生成代码把这个状态保存到va_list中在LowerVAARG里要根据参数类型决定从哪个区域取值。这个过程中最麻烦的是处理“参数类型在寄存器区和栈区之间切换”的场景比如printf这种格式字符串里%d、%f混合出现的调用。尾调用优化。AAPCS64 对尾调用有特殊要求尾调用时被调用者的栈帧必须已经释放并且参数尽可能复用当前函数的寄存器/栈位置避免额外压栈。如果后端在尾调用时重新分配了参数寄存器而又没有处理好生命周期就会把仍在使用中的参数覆盖掉。我在调试过程中见过一个案例尾调用优化开启后某个浮点参数的精度偶尔出错最后定位发现是编译器在尾调用的参数重分配过程中把一个v0里的值搬到了v1但原来的v0又被用于传一个整数指针导致双方互相覆盖。4.4 如何验证你的改法符合 ABI工具链测试矩阵编译器后端的改动不能只靠眼力必须有一套验证矩阵。我的做法分三层单元级针对每个函数原型写一个简单的测试 C 文件编译后检查汇编是否符合预期。重点覆盖基本类型、结构体、联合体、长整数、双精度浮点、向量类型和可变参数。交互级把新后端编译出来的目标文件和旧工具链编译的目标文件链接在一起跑一个包含大量 API 调用的测试程序。这样能检查调用约定是否真的双方一致。系统级在真实 ARM 设备或 QEMU 用户态模拟器上跑完整的测试套件。对于 AArch64 来说QEMU 用户态模式已经能覆盖绝大部分指令和系统调用场景如果涉及 SVE 等特性需要开启对应的cpu参数。实际经验交互级测试是三个里面最容易被忽视但最能发现问题的。因为单元级测试里编译器和链接器“自己配自己”就算 ABI 实现有误也可能碰巧一致系统级测试又往往被工具链环境差异干扰。只有交互级一边用新后端、一边用老工具链强制两边“谈判”才能暴露真实契约偏差。5. 常见问题与排查技巧实录5.1 ABI 不一致导致的典型崩溃与快速定位我整理了一下自己在实际项目中遇到过的 ABI 相关崩溃基本都逃不出这几类现象可能原因快速排查方法函数返回后栈指针不对函数指针跳飞调用约定中参数寄存器布局不一致编译后用readelf --debug-dumpframes查看 CFI或objdump -d对比两个编译单元的序言/尾声结构体字段错位结构体传递规则版本不一致用ptype或pahole查看结构体布局检查#pragma pack和-mabi选项可变参数读到垃圾值va_list的栈/寄存器偏移算法不一致反汇编调用点和va_start的展开代码观察gr_offs/vr_offs的赋值全局变量访问地址异常重定位类型或 GOT 条目生成错误readelf -r检查.rela.dyn类型用LD_DEBUGreloc运行时观察动态链接器行为NATO/NEON 向量寄存器被破坏被调用者保存寄存器规则未正确遵守观察-fomit-frame-pointer模式下被调用者是否保存了v8-v15等寄存器定位这些问题的通用思路是找一个最小复现用例编译成汇编再对照 arm-abi-aa 里的文档逐步排除。不要一上来就到大型项目里翻日志效率太低。5.2 工具链之间的“ABI 版本错配”问题我遇到过最魔幻的现场是两边用的都是aarch64-linux-gnu-gcc但一个用的 8.x一个用的 13.x结果同一个函数传struct { long a; long b; }都能传错。查下来发现问题不在寄存器分配而在编译选项一边用了-mgeneral-regs-only另一边默认开了 VFP。这就导致一边认为浮点和向量参数走通用寄存器另一边认为走向量寄存器。这是 ABI 审计里非常现实的问题纸面上的 AAPCS64 只有一套但实际工具链因为配置差异、特性开关、版本演进会产生各种“方言”。所以我在做编译器落地时一定会先把目标平台的编译选项固定下来整理成一份“构建配置基线”。这份基线和 arm-abi-aa 仓库里的规范一起才是一个完整的、可审计的 ABI 契约。5.3 交叉编译与链接时最容易被忽略的默认行为交叉编译时很多人只顾着指定--targetaarch64-linux-gnu却忽略了链接器的默认脚本和库路径。AArch64 的 ELF 加载模型里有一个ld默认生成的_DYNAMIC链接信息它依赖.dynamic段里各项的正确性任何一项不对动态链接器都会罢工。另外-Wl,-z,now和-Wl,-z,lazy的选择也会影响 GOT 表项的填充时机这在排查“一启动就崩”和“运行到某个函数才崩”的区别时非常关键。如果你用readelf -d看到FLAGS里有NOW就知道所有符号都绑定了启动时就会解析完所有 GOT 项。5.4 写一个最小的 ABI 一致性验证工具除了已有的工具链我建议你在自己的项目里维护一个很小的“ABI 探针”程序。它不需要多复杂只要能做这几件事定义一组包含各种基本类型和结构体的函数原型。编译成静态库或动态库提供get_version之类的导出函数。在宿主程序里以相同原型调用这些函数检查返回值和缓冲区内容。当工具链升级或者更换交叉编译目标时先编译这个探针并跑通再上大项目。我在团队里把这个叫做“先签合同再打仗”能省下大量排查 ABI 错配的时间。5.5 审计过程中的“高频记忆点”速查最后分享几个我审计时会特别圈出来的关键条款它们分布在 arm-abi-aa 不同文档里但又互相影响AAPCS64 中x8是间接结果寄存器。如果一个函数返回大型结构体x8会持有返回值的地址函数内部要往x8指向的内存写结果。这个规则对于手写汇编尤其重要容易忽略。函数入口的sp必须 16 字节对齐但 AAPCS64 并没有强制要求栈向下增长所以编译器在序言里的常见动作是sub sp, sp, #N其中 N 通常是 16 的倍数。AArch64 的重定位枚举值按类型分组数据重定位、指令重定位、GOT 相关、PLT 相关各有区间。你可以用readelf -r连续看几个条目就能快速判断目标文件的链接需求。异常展开时AArch64 的.eh_frame里记录的是叫“状态”的规则CFI 指令可以精确描述栈指针偏移和寄存器恢复位置。调试崩溃时gdb的bt能不能正确打印调用栈基本就取决于这一块。写在最后坦白说arm-abi-aa 这套内容本身不会直接让你的程序跑得更快但它是你在做编译器开发、工具链移植、固件安全审计时绕不开的“底层法律”。我个人的习惯是不把它当一次性读物而是当成一个不断回来对齐的基准。每次在 LLVM 后端改了调度策略、调整了调用约定、甚至只是升级了 Clang 版本我都会重新去仓库里对照相应章节确认自己的实现没有被某条细节条款打脸。如果你也在做编译器后端或者交叉工具链相关的事建议先从一个小函数开始走一遍“规范→汇编→readelf”的验证链路。等你把这条链路跑顺了再面对那些复杂特性SVE、PAuth、MTE时就不会觉得 ABI 是玄学而是一套可以被审计、被实现、被验证的工程契约。
解析arm-abi-aa：从ABI契约到编译器落地的实战指南
这篇内容不是给你念 ARM 的 Datasheet也不是整理一份“AArch64 指令大全”。我想聊的是arm-abi-aa这套源码仓库背后的设计逻辑以及一个做编译器落地的人该怎么去读它、审它并且真正把它用到自己的工具链开发里。先说清楚这是什么。arm-abi-aa是 ARM 官方维护的 ABI 规范仓库里面存的不只是 AAPCS64 那一份 PDF而是一整套与 AArch64/AArch32 调用约定、数据类型、重定位模型、异常展开、DWARF 调试信息相关的文档和定义。它决定了你的 C 函数怎么传参、结构体怎么对齐、汇编器怎么生成重定位、链接器怎么解析符号甚至连调试器怎么恢复栈帧都跟它有关系。作为一个常年跟编译器后端打交道的人我的建议是不要把它当成“参考手册”去翻要当成“源码”去审。这个仓库里的每一条规范背后都有对应的 LLVM/GCC 实现、binutils 处理逻辑和实际硬件行为。这篇文章我会从整体架构、审计路线、核心细节、编译器落地几个维度拆开讲最后再给你一份我平时排查 ABI 相关问题时的实操笔记。1. Arm-abi-aa 全景拆解这套仓库到底管了哪些事1.1 从 AAPCS 到 arm-abi-aa为什么说“ABI 仓库”不等于“一份 PDF”很多人对 AAPCSProcedure Call Standard for the ARM Architecture的印象停留在“32 位时代的传参规则”但arm-abi-aa仓库里的内容远不止这些。它把 ARM 架构的 ABI 拆成了多个维度分别用独立的文档或源码模块维护。我列一下核心组成你在仓库根目录基本都能找到对应目录或文件AAPCS64AArch64 架构的过程调用标准这是最核心的一份定义了参数寄存器、栈帧布局、结构体传递规则。AAPCS32AArch32也就是 ARMv7 及之前的过程调用标准和 AAPCS64 有不少差异。ABI for the C LanguageC 语言层面的 ABI包括基本数据类型的大小、对齐方式、枚举类型映射等。ELF ABI for the ARM ArchitectureELF 文件格式在 ARM 上的具体要求包含重定位类型定义、节区命名规则、属性节区等。ABI for DWARF调试信息格式在 ARM 上的约束涉及 DWARF 寄存器编号映射、CFI 规则等。Exception Handling ABI异常展开unwinding相关的 ABI 规范AArch64 上用的.eh_frame和旧式 ARM 的EXIDX都在这里定义。这个仓库存在的意义是它不光是给读书人看的规范更是给工具链实现者对照的“契约”。LLVM 后端在实现调用约定时不是自己拍脑袋设计而是直接对照 AAPCS64 的条款来实现。同样binutils 里readelf解析重定位条目时也是按照 ELF ABI 文档里的定义去解码的。1.2 版本演进与仓库里的“时间线”我在审计这个仓库时注意到一个很关键的问题ABI 是分版本演进的而且不同版本的 GCC/LLVM 可能实现了不同版本的 ABI。仓库里会保留历史版本的规范文档或者在一个文档里通过修订记录标注变化点。比如 AArch64 的 AAPCS 就有过关于 SVE可扩展向量扩展和 SME可扩展矩阵扩展的补充规范这些后来都被合入了主文档或新增了独立章节。用实际例子说明早期 AAPCS64 对va_list的定义是一个指向参数栈区域的指针但后来 ARM 引入了“参数在寄存器中传递时va_list也要能访问到寄存器中的值”的规则于是va_list变成了一个结构体里面包含了__stack、__gr_top、__vr_top、__gr_offs、__vr_offs等字段。如果你用的编译器版本和库文件版本不一致解析可变参数时就可能出现完全不符合预期的地址这正是 ABI 版本错配的典型坑。注意读这种仓库第一步不是去背条款而是先看清这个仓库的“版本-硬件特性-编译器实现”三者的对应关系。我一般会在仓库里先搜SVE、SME、PAuth指针认证、MTE内存标记扩展这些关键词确认目标平台开启的特性再决定用哪套 ABI 规则去约束自己的代码生成。2. 源码审计路线图先建“ABI→实现”映射再逐层下钻2.1 审计前需要建立的全局视图如果你直接打开 arm-abi-aa 仓库一篇篇读大概率会陷入细节出不来。我建议你先把整个仓库当成一份源码项目的根目录然后建立一张映射表把“规范文档的哪个小节”对应到“LLVM/GCC 的哪个文件哪个函数”。这样审计时才有抓手而不是漫无目的地浏览。我自己的映射思路大概是这样的ABI 主题规范文档位置LLVM 侧关键文件binutils 侧关键工具整型/指针参数传递AAPCS64Procedure Call StandardAArch64ISelLowering.cpp里LowerFormalArguments、LowerCallllvm-readobj查看生成的 reloc浮点/向量参数传递AAPCS64 中VFP相关小节AArch64ISelLowering.cpp的CC_AArch64相关代码readelf -A查看属性结构体返回AAPCS64 里Composite Types小节AArch64TargetLowering中CC_AArch64处理sret的逻辑objdump -d观察调用点栈对齐AAPCS64 的Stack ConstraintsAArch64FrameLowering.cpp中emitPrologue、emitEpilogueobjdump -d检查sub sp, sp, #Nva_listAAPCS64的Variadic实现AArch64ISelLowering.cpp中LowerVAARG、LowerVASTART观察va_arg展开前后的地址计算重定位ELF ABI 章节ELFObjectWriter.cpp中的重定位类型发射readelf -r查看.rela.*条目这张表的作用不是让你背下来而是给你一个审计起点。你读规范时遇到一条规则就要问自己这条规则在 LLVM 的哪个函数里体现我能不能用readelf或者objdump造一个反例来验证2.2 审计的四个核心模块我一般把审计分成四条线每条线都对应一个独立的 ABI 关注点第一条线调用约定Calling Convention。这是最高频的 ABI 场景。目标很明确AArch64 下整数、指针、浮点、向量参数各走哪些寄存器超出部分怎么压栈结构体怎么拆分。审计重点是x0-x7和v0-v7的分配规则以及x8这个“间接结果寄存器”的处理。第二条线内存布局与数据模型。C 语言的char、short、int、long、指针在 AArch64 下分别是多少位、多少字节对齐long double到底是 16 字节 IEEE 754 还是 128 位扩展精度这些直接决定结构体大小和偏移一旦和库文件不一致轻则数据错位重则直接越界。第三条线重定位模型。AArch64 有大量与位置无关代码PIC相关的重定位类型比如R_AARCH64_ADR_PREL_PG_HI21负责计算某个符号所在页的地址配合R_AARCH64_ADD_ABS_LO12_NC形成页内偏移。审计时要注意不同重定位类型的语义以及编译器在什么场景下会使用GOT全局偏移表。第四条线异常展开与调试信息。AArch64 使用.eh_frame来记录栈展开规则DWARF CFI 指令会被编码到.eh_frame里。审计时重点看栈指针、帧指针的恢复规则以及RA_SIGN_STATE这种和指针认证相关的伪寄存器怎么处理。2.3 审什么、怎么审具体操作步骤我这里给出一个可复制的审计流程如果你没有太多经验直接按这个流程走就行拉取仓库把arm-abi-aa仓库克隆到本地同时准备一份 LLVM 源码和一个 AArch64 的交叉编译工具链。选择切入点从一个简单的 C 函数开始比如int add(int a, int b) { return a b; }编译成汇编。翻阅对应规范打开 AAPCS64 文档找到整数参数传递部分确认a放w0、b放w1、返回值放w0。对照实现在 LLVM 源码里搜索AArch64ISelLowering.cpp找到LowerFormalArguments看它是怎么根据CC_AArch64分配寄存器的。造反例验证改掉某个参数的类型或顺序比如把int改成double观察寄存器分配的变化再回到规范里找对应条款。这套流程走完你对一个模块的 ABI 理解会比单纯读十遍文档都深。因为你在“规范→实现→结果”三者之间建立了一条完整的验证链路。3. 核心 ABI 细节深挖调用约定、数据模型与重定位模型3.1 调用约定里最容易被忽略的“规则优先级”AAPCS64 对参数传递的规则写得比较细但初学者很容易只记住“前 8 个整型参数用 x0-x7”却忽略了两个关键点一是参数类型和数量共同决定寄存器分配。比如函数void f(double a, int b, float c)在 AArch64 里a走d0b走w1c走s2它们各自有独立的编号空间。这里并不是把整型和浮点混在一起统编的浮点用浮点寄存器序列整型用整型寄存器序列。审计时要特别留意因为写后端时最容易在这类“双轨分配”上出错。二是结构体的“奇异”传递规则。AAPCS64 规定如果一个结构体的大小是 1、2、4、8、16 字节且成员都是“单一基本数据类型组合”它可能被当作一个“基本数据类型”来传递。比如struct { int a; float b; }这个 8 字节结构体在double寄存器里按一个 64 位值传递但如果结构体里有超过 16 字节的数组或者成员对齐要求变高就会退化为“内存传递”——通过隐式指针传参。这里有一个典型的坑我在审计时见过一个案例两个团队分别编译同一个函数接口一边用 GCC 编译一边用 Clang 编译双方对同一个结构体的传递方式产生了分歧。原因是该结构体大小是 24 字节按照 AAPCS64 应该走内存传递但其中一边的头文件里结构体定义不对导致编译器认为它只有 16 字节于是按寄存器传。结果就是两边函数调用约定不一致运行起来直接拿到垃圾参数。3.2 AArch64 的数据模型和栈布局到底怎么算AArch64 下常用数据模型是 LP64也就是long和指针都是 64 位int是 32 位。这看起来没什么好讲的但配合栈对齐规则就有意思了。AAPCS64 要求在执行函数调用之前栈指针必须 16 字节对齐。也就是说在一个函数入口sp是 16 字节对齐的调用下一个函数之前当前函数需要保证sp减去参数区和局部变量区后仍然 16 字节对齐。这听起来简单但要做对编译器必须综合考虑参数压栈数量、局部变量大小、帧指针是否使用等多种因素。我来算一个实际例子假设一个函数有两个局部变量一个int4 字节、一个double8 字节同时它还要调用子函数子函数有 2 个栈传参数各 8 字节那么当前函数可能会在序言里执行类似sub sp, sp, #32的操作。这 32 字节怎么来的参数区 16 字节、局部变量可能要 16 字节为了对齐8 字节变量往往要额外垫 8 字节来满足 16 对齐。如果你手写汇编算错一位调用子函数时栈不对齐碰到用对齐指令如ldp/stp的场景就会崩溃。实操心得碰到栈对齐问题不要去猜直接用objdump -d看生成的指令或者用readelf -wf看.eh_frame里的 CFI 规则里面记录了函数出入口栈指针的变化量。这个比看多少文档都直观。3.3 重定位模型PIC、GOT 与页寻址的联动AArch64 的指令长度固定 32 位所以一条adrp指令只能编码一个 21 位的页偏移page offset配合 12 位的页内立即数偏移总共可以寻址 4GB 范围。这个设计决定了它在生成位置无关代码时经常需要两条指令配合来引用一个全局变量adrp x0, symbolPAGE add x0, x0, symbolPAGEOFFPAGE和PAGEOFF对应的重定位类型分别是R_AARCH64_ADR_PREL_PG_HI21有的实现也叫ADR_PREL_PG_HI21和R_AARCH64_ADD_ABS_LO12_NC。在审计 ELF ABI 文档时你要特别关注这些重定位类型的计算方式它们算的是符号所在页和当前指令所在页的偏移而不是符号本身的绝对地址。再往深一层如果要支持动态链接全局变量可能要走 GOT。这时编译器生成的是adrp x0, :got:variable然后ldr x0, [x0, #:got_lo12:variable]最终通过 GOT 表项拿到变量的真实地址。AArch64 的:got:重定位类型在 LLVM 和 binutils 里都有实现但细节差别要注意GOT 条目大小、对齐方式、是否使用LD64_GOT_LO12_NC等都会影响最终链接结果。我在审计 binutils 的readelf -r输出时会特别关注.rela.plt和.rela.dyn里的条目观察哪些是JUMP_SLOT、哪些是GLOB_DAT、哪些是RELATIVE。因为这几个类型的处理方式在动态链接器里不同JUMP_SLOT用于函数地址解析GLOB_DAT用于数据地址解析RELATIVE用于基于加载基址的重定位。这类问题在交叉编译场景下特别容易踩坑尤其是你自己写链接脚本或者做裸机/RTOS 启动代码时处理错一个重定位类型程序加载后访问的地址就是错的。提示如果你在排查一个“在可执行文件里正常在共享库里崩溃”的问题第一反应应该是去看重定位是否发生了变化而不是去怀疑代码逻辑。把.so里符号的地址分布和.rela.dyn对齐往往能快速锁定问题范围。4. 从 ABI 规范到编译器后端在 LLVM 里落地的完整路径4.1 找对入口文件AArch64 后端的关键代码地图如果说 arm-abi-aa 是“契约”那么 LLVM 的 AArch64 后端就是“实现”。你要做编译器开发落地必须清楚地知道契约的每一条在代码里的形状。我给出几个你一定会用到的文件AArch64ISelLowering.cpp这是指令选择层里最核心的文件LowerFormalArguments负责处理函数入口的参数LowerCall负责处理调用点的参数准备LowerVAARG处理va_arg。AArch64CallingConvention.td这个 TableGen 文件定义了多个调用约定比如CC_AArch64_AAPCS、CC_AArch64_Darwin、CC_AArch64_Apple等。改调用约定通常从这里开始。AArch64FrameLowering.cpp栈帧布局和序言/尾声指令的生成在这里栈对齐、帧指针、叶函数优化都在这处理。AArch64Subtarget.cpp特性开关在这里定义比如是否支持 SVE、是否支持 PAuth这些特性会直接影响 ABI 的某些分支处理。有一个比较实用的经验如果你想快速验证“某个参数类型在 AAPCS64 里到底怎么传”不用去翻文档熬时间直接在 LLVM 源码里跑一个小实验。写一个 C 函数编译成 LLVM IR然后用llc指定 AArch64 后端强制输出汇编观察x0-x7、v0-v7和栈的使用同时和AArch64CallingConvention.td里的规则对照。4.2 调试后端时的常用手段从 IR 到汇编的逐步下钻LLVM 后端调试有一个很顺手的流程我基本每天都会用先写好 C 源文件用clang --targetaarch64-linux-gnu -S直接出汇编快速确认 ABI 层面没问题。再用clang --targetaarch64-linux-gnu -O0 -emit-llvm生成 IR手动或自动进行指令选择。想看 SelectionDAG 阶段的信息用llc -view-dag-combine1-dags之类的选项可以图形化观察 DAG 变化但如果没有图形界面就用-debug-onlyisel打印日志。想看最终指令和寄存器分配用llc -stop-aftermachine-cp之类的参数控制编译阶段逐步观察。这套流程对我来说最大的价值是它把“ABI 规范”和“编译器生成结果”真正串起来。比如你想知道 AAPCS64 对 16 字节结构体传参的规则直接写一个 16 字节结构体的函数从 IR 往下跟看到CC_AArch64_AAPCS如何把它拆到两个 64 位寄存器里比读条文要直观得多。4.3 落地时最容易出错的三个点寄存器保存、可变参数、尾调用寄存器保存策略。AArch64 下x19-x28是被调用者保存的x9-x15是临时寄存器x16、x17是 intra-procedure-call 临时寄存器。后端在生成函数序言时要决定哪些被调用者保存的寄存器需要压栈分析每个函数实际用到了哪些。如果分析错了比如少保存了一个寄存器函数返回后调用者的局部变量被破坏这类 bug 极其隐蔽因为它只在特定代码路径下才出现。可变参数。C 数va_list在 AArch64 上是一个结构体里面记录了通用寄存器区、浮点寄存器区、栈区的当前状态。LLVM 后端在LowerVASTART里要生成代码把这个状态保存到va_list中在LowerVAARG里要根据参数类型决定从哪个区域取值。这个过程中最麻烦的是处理“参数类型在寄存器区和栈区之间切换”的场景比如printf这种格式字符串里%d、%f混合出现的调用。尾调用优化。AAPCS64 对尾调用有特殊要求尾调用时被调用者的栈帧必须已经释放并且参数尽可能复用当前函数的寄存器/栈位置避免额外压栈。如果后端在尾调用时重新分配了参数寄存器而又没有处理好生命周期就会把仍在使用中的参数覆盖掉。我在调试过程中见过一个案例尾调用优化开启后某个浮点参数的精度偶尔出错最后定位发现是编译器在尾调用的参数重分配过程中把一个v0里的值搬到了v1但原来的v0又被用于传一个整数指针导致双方互相覆盖。4.4 如何验证你的改法符合 ABI工具链测试矩阵编译器后端的改动不能只靠眼力必须有一套验证矩阵。我的做法分三层单元级针对每个函数原型写一个简单的测试 C 文件编译后检查汇编是否符合预期。重点覆盖基本类型、结构体、联合体、长整数、双精度浮点、向量类型和可变参数。交互级把新后端编译出来的目标文件和旧工具链编译的目标文件链接在一起跑一个包含大量 API 调用的测试程序。这样能检查调用约定是否真的双方一致。系统级在真实 ARM 设备或 QEMU 用户态模拟器上跑完整的测试套件。对于 AArch64 来说QEMU 用户态模式已经能覆盖绝大部分指令和系统调用场景如果涉及 SVE 等特性需要开启对应的cpu参数。实际经验交互级测试是三个里面最容易被忽视但最能发现问题的。因为单元级测试里编译器和链接器“自己配自己”就算 ABI 实现有误也可能碰巧一致系统级测试又往往被工具链环境差异干扰。只有交互级一边用新后端、一边用老工具链强制两边“谈判”才能暴露真实契约偏差。5. 常见问题与排查技巧实录5.1 ABI 不一致导致的典型崩溃与快速定位我整理了一下自己在实际项目中遇到过的 ABI 相关崩溃基本都逃不出这几类现象可能原因快速排查方法函数返回后栈指针不对函数指针跳飞调用约定中参数寄存器布局不一致编译后用readelf --debug-dumpframes查看 CFI或objdump -d对比两个编译单元的序言/尾声结构体字段错位结构体传递规则版本不一致用ptype或pahole查看结构体布局检查#pragma pack和-mabi选项可变参数读到垃圾值va_list的栈/寄存器偏移算法不一致反汇编调用点和va_start的展开代码观察gr_offs/vr_offs的赋值全局变量访问地址异常重定位类型或 GOT 条目生成错误readelf -r检查.rela.dyn类型用LD_DEBUGreloc运行时观察动态链接器行为NATO/NEON 向量寄存器被破坏被调用者保存寄存器规则未正确遵守观察-fomit-frame-pointer模式下被调用者是否保存了v8-v15等寄存器定位这些问题的通用思路是找一个最小复现用例编译成汇编再对照 arm-abi-aa 里的文档逐步排除。不要一上来就到大型项目里翻日志效率太低。5.2 工具链之间的“ABI 版本错配”问题我遇到过最魔幻的现场是两边用的都是aarch64-linux-gnu-gcc但一个用的 8.x一个用的 13.x结果同一个函数传struct { long a; long b; }都能传错。查下来发现问题不在寄存器分配而在编译选项一边用了-mgeneral-regs-only另一边默认开了 VFP。这就导致一边认为浮点和向量参数走通用寄存器另一边认为走向量寄存器。这是 ABI 审计里非常现实的问题纸面上的 AAPCS64 只有一套但实际工具链因为配置差异、特性开关、版本演进会产生各种“方言”。所以我在做编译器落地时一定会先把目标平台的编译选项固定下来整理成一份“构建配置基线”。这份基线和 arm-abi-aa 仓库里的规范一起才是一个完整的、可审计的 ABI 契约。5.3 交叉编译与链接时最容易被忽略的默认行为交叉编译时很多人只顾着指定--targetaarch64-linux-gnu却忽略了链接器的默认脚本和库路径。AArch64 的 ELF 加载模型里有一个ld默认生成的_DYNAMIC链接信息它依赖.dynamic段里各项的正确性任何一项不对动态链接器都会罢工。另外-Wl,-z,now和-Wl,-z,lazy的选择也会影响 GOT 表项的填充时机这在排查“一启动就崩”和“运行到某个函数才崩”的区别时非常关键。如果你用readelf -d看到FLAGS里有NOW就知道所有符号都绑定了启动时就会解析完所有 GOT 项。5.4 写一个最小的 ABI 一致性验证工具除了已有的工具链我建议你在自己的项目里维护一个很小的“ABI 探针”程序。它不需要多复杂只要能做这几件事定义一组包含各种基本类型和结构体的函数原型。编译成静态库或动态库提供get_version之类的导出函数。在宿主程序里以相同原型调用这些函数检查返回值和缓冲区内容。当工具链升级或者更换交叉编译目标时先编译这个探针并跑通再上大项目。我在团队里把这个叫做“先签合同再打仗”能省下大量排查 ABI 错配的时间。5.5 审计过程中的“高频记忆点”速查最后分享几个我审计时会特别圈出来的关键条款它们分布在 arm-abi-aa 不同文档里但又互相影响AAPCS64 中x8是间接结果寄存器。如果一个函数返回大型结构体x8会持有返回值的地址函数内部要往x8指向的内存写结果。这个规则对于手写汇编尤其重要容易忽略。函数入口的sp必须 16 字节对齐但 AAPCS64 并没有强制要求栈向下增长所以编译器在序言里的常见动作是sub sp, sp, #N其中 N 通常是 16 的倍数。AArch64 的重定位枚举值按类型分组数据重定位、指令重定位、GOT 相关、PLT 相关各有区间。你可以用readelf -r连续看几个条目就能快速判断目标文件的链接需求。异常展开时AArch64 的.eh_frame里记录的是叫“状态”的规则CFI 指令可以精确描述栈指针偏移和寄存器恢复位置。调试崩溃时gdb的bt能不能正确打印调用栈基本就取决于这一块。写在最后坦白说arm-abi-aa 这套内容本身不会直接让你的程序跑得更快但它是你在做编译器开发、工具链移植、固件安全审计时绕不开的“底层法律”。我个人的习惯是不把它当一次性读物而是当成一个不断回来对齐的基准。每次在 LLVM 后端改了调度策略、调整了调用约定、甚至只是升级了 Clang 版本我都会重新去仓库里对照相应章节确认自己的实现没有被某条细节条款打脸。如果你也在做编译器后端或者交叉工具链相关的事建议先从一个小函数开始走一遍“规范→汇编→readelf”的验证链路。等你把这条链路跑顺了再面对那些复杂特性SVE、PAuth、MTE时就不会觉得 ABI 是玄学而是一套可以被审计、被实现、被验证的工程契约。
