ARM64汇编入门：寄存器模型、指令集与GDB调试实战

简介：面向ARM平台入门学习者与逆向工程初学者的一份汇编基础教程文档，围绕ARM处理器版本与指令集映射、.s文件经as汇编和ld链接生成可执行程序的过程、有符号/无符号字/半字/字节数据类型、大端/小端字节序及CPSR的E位控制等展开。教程用较大篇幅梳理R0-R15通用寄存器与SP、LR、PC、CPSR各自的职责，并结合函数调用约定说明前四个参数如何通过R0-R3传递、返回地址如何由LR保存，为后续内存读写、条件分支、栈与函数等进阶主题提供必要基础。压缩包内含1个docx文档，约2.65MB，适合对照学习、离线查阅或作为入门笔记；目前已有209人学习下载。文末还整理了多篇英文扩展阅读链接，可进一步了解树莓派上的ARM汇编实践与逆向工程应用。

1. 动手前先搞懂ARM汇编在解决什么问题

如果你第一次翻开ARM汇编相关的文档，大概率会被满屏的指令格式劝退。但我的经验是：卡住你的从来不是指令多，而是你还没建立“寄存器是主角，内存只是仓库”这个观念。ARM汇编基础教程第一课，想讲清楚的就是这套底层心智模型。

这篇笔记以ARM64（AArch64）为主线，带你走完一条完整路径：寄存器模型、指令集骨架、交叉编译环境、最小可运行程序、函数调用与GDB调试。适合三类人：一是写固件启动代码的嵌入式开发者，二是做Android底层或性能优化的应用工程师，三是做固件逆向分析的安全从业者。学完之后，你能自己编译一个ARM64汇编程序并在模拟器上跑通，还能用调试器单步看每一条指令的执行过程。

2. ARM寄存器模型与指令集：这块地基决定了你后面会不会翻车

2.1 为什么ARM要做成load/store架构而不是x86那套

x86允许指令直接操作内存，比如add [eax], 1这种写法。ARM没有走这条路，它把指令分成了两类：一类是load/store，负责在内存和寄存器之间搬数据；另一类是运算指令，只允许操作寄存器。这种设计有两个直接后果。

第一，任何数据参与运算之前，必须先被加载到寄存器里。第二，运算结果想写回内存，必须显式用store指令。这个约束看起来多此一举，但它让每条指令的语义变简单，硬件流水线更容易做乱序执行和分支预测，功耗也能压得更低。你在学的时候请记住一句话：ARM里没有“内存操作数”这回事。

这种架构带来的另一个好处是寻址方式统一。内存访问指令的寻址模式就那么几种：基址寄存器、基址加偏移、带前变址和后变址。比起x86那种动不动就是好几页的寻址组合，ARM的规则相当规整。后面写代码时你会发现，90%的访存指令用到的就是ldr/str加一个偏移量。

2.2 通用寄存器、专用寄存器与调用约定：先背熟这五条规则

AArch64给你提供了31个64位通用寄存器，名字从x0到x30，每个都有对应的32位别名，也就是w0到w30。写w0只操作低32位，写x0会覆盖整个64位。这个设计让你在同一个寄存器上既能做32位运算又能做64位运算，省去不少类型转换指令。

第一个必须记住的规则：x0到x7是参数寄存器，函数调用时前八个参数按顺序放在这里，返回值也放x0。第二个规则：x19到x28是被调用者保存的寄存器，意思是你在函数里用了它们就得在返回前恢复原值，否则调用方会遭到无妄之灾。第三个规则：x29是帧指针，x30是链接寄存器，x30被bl指令自动写入返回地址。第四个规则：sp是栈指针，必须保持16字节对齐。第五个规则：xzr是零寄存器，读它永远得到0，写它等于丢弃结果。

这五条规则基本就是AAPCS64调用约定的精简版。你可以暂时不背全条款，但参数寄存器、链接寄存器、零寄存器这三样必须刻进脑子里。后面调试的时候你大概率会频繁检查x0、x30和sp这三个东西。

2.3 常用指令的最小集：mov/add/sub/cmp/b/ldr/str/bl/ret

不需要一开始就把ARM指令集从头到尾过一遍。实际写启动代码和裸机程序，翻来覆去的核心指令不超过二十条。先把下面这九条抠熟，足以应付第一阶段的绝大多数场景。

• mov x0, #1：把立即数1送到x0。注意立即数长度有限制，后面避坑章节会专门讲。
• add x0, x1, x2：x0 = x1 + x2。ARM的GNU汇编语法是目标寄存器在左边，这一点别搞反。
• sub x0, x1, #8：x0 = x1 - 8。
• cmp x0, x1：做一次减法但不保存结果，只更新NZCV条件位，本质是影响状态标志。
• b label：无条件跳转到label处执行。
• b.gt label：条件跳转，当上次cmp结果满足“大于”时跳转。
• ldr x0, [x1]：从x1指向的内存地址读64位到x0。
• str x0, [x1]：把x0的值写到x1指向的内存。
• bl func：先跳转到func，同时把下一条指令的地址写入x30。ret则是通过x30里的地址跳回去。

每个指令都可以跟条件后缀，比如add.ne表示上一次比较不等时才执行。这个特性叫条件执行，是ARM的老传统，虽然到了ARM64被大幅削弱，但你会在比较和分支的组合中反复用到。

2.4 条件位NZCV与条件执行：b.le不是魔法

条件跳转的底层是PSTATE寄存器里的四个位：N（负数）、Z（零）、C（进位）、V（溢出）。cmp指令做的事就是算一次减法，然后按结果设置这四个位。比如cmp x0, x1，如果x0等于x1，Z位为1；x0小于x1，N位为1；如果减法没产生借位，C位为1。

条件跳转指令就是读这些位的组合。b.le表示“小于或等于”，它在内部判断的是 Z=1 或 N!=V。你不需要背真值表，但要知道关键一点：比较和跳转是两条独立的指令，中间被其他指令插入的话，NZCV可能被改掉。调试时如果发现跳转方向不对，先去看cmp和b.cond之间有没有混入其他会改状态位的指令。

这一段学完，你已经有了最基本的指令骨架。下一步要做的是把环境搭起来，让这些指令真正跑起来。

3. 用交叉工具链把第一条ARM指令跑起来

3.1 安装工具链和用户态模拟器

你在x86电脑上写的ARM程序，没法直接运行，需要交叉编译器把源码变成AArch64指令，再靠模拟器在本地执行。常见做法是装三件套：GNU交叉工具链、qemu用户态模拟器、gdb-multiarch调试器。

sudo apt install gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu qemu-user gdb-multiarch

装完之后验证一下工具链是否工作。aarch64-linux-gnu-as是汇编器，aarch64-linux-gnu-ld是链接器，aarch64-linux-gnu-objdump是反汇编工具。这三个是后面最常用的。gcc包主要是为了以后把C和汇编混编时用，现在只用as和ld就够。

qemu-user的作用是直接运行AArch64 Linux用户态程序，它不用模拟整个硬件，只是做CPU指令翻译，跑汇编教学代码绰绰有余。需要注意一点：qemu运行动态链接的ARM程序时需要指定解释器路径，我会在下面命令里直接带上-L /usr/aarch64-linux-gnu，这样能避开一系列“找不到动态链接器”的报错。

3.2 第一份汇编源码：用write系统调用打印一行字

写汇编程序的入门仪式是打印一行字。不走C库，直接调Linux的write系统调用，这样你能看清从寄存器到系统调用号的全过程。

// hello.S — 用Linux系统调用输出一行文本 // 目标平台：ARM64 (AArch64)，GNU as 语法 .text .global _start // 链接器从这里找入口 _start: mov x0, #1 // 文件描述符 1 = 标准输出 ldr x1, =msg // x1 = 字符串首地址 mov x2, #len // x2 = 字符串字节数 mov x8, #64 // 64 是 write 的系统调用号 svc #0 // 触发系统调用 mov x0, #0 // 退出码 0 mov x8, #93 // 93 是 exit 的系统调用号 svc #0 .data msg: .ascii "Hello, ARM!\n" .equ len, . - msg // 用当前地址减起始地址计算长度

这段代码的第二个系统调用容易漏。如果你不调用exit就结束程序，内核会给你返回一个段错误，因为CPU跑完了数据段里的字节。.equ len, . - msg是汇编器计算字符串长度的惯用写法，.代表当前地址，减掉msg的起始地址，得到的就是字节数，结束符‘\n’也算在内。

3.3 编译、链接、运行：三条命令背后的坑

汇编和链接是两个步骤，别一上来就用gcc一把梭，那样会隐式引入C运行时，反而不利于理解程序入口。

aarch64-linux-gnu-as -o hello.o hello.S aarch64-linux-gnu-ld -o hello hello.o qemu-aarch64 -L /usr/aarch64-linux-gnu ./hello

如果一切正常，终端会打印出 Hello, ARM!。如果qemu报找不到/lib/ld-linux-aarch64.so.1，几乎可以确定是你没加-L参数，或者工具链的sysroot路径不对。

链接这一步有玄学成分：如果你把_start的名字写错，链接器会报“找不到入口符号”。GNU ld默认的入口名就是_start，所以不要在链接脚本里搞特殊化，就让入口保持在_start，这是最不容易犯错的路子。

3.4 用反汇编验证你的源码真的变成ARM指令

汇编器把你的文本变成机器码的过程是个黑匣子，最好自己拆开看一眼。用objdump反汇编生成的可执行文件：

aarch64-linux-gnu-objdump -d hello

你会看到每一行源码对应的AArch64指令，比如mov x0, #0x1这样的反汇编输出，并且能看到每条指令的长度都是4字节。建议你重点看ldr x1, 0x...那行，它后面往往跟着一个数值，那是汇编器自动生成的文字池，也就是存放msg地址的隐藏常量。

对照一下源码和反汇编，你会发现汇编源码里的ldr x1, =msg被拆成了加载指令加一个文字池条目。这个细节直接关联到后面避坑章节讲的立即数加载问题。

4. 写一个真正的ARM汇编程序：循环累加与函数调用

4.1 从main函数到系统调用：汇编里的“入口”到底是什么

很多从C语言转过来的人会下意识找main。但汇编程序不归C运行时管，入口就是链接器指定的那个符号。上一章的_start就是入口，它由链接器写入可执行文件的头部，操作系统加载程序后直接从这里开始执行。

如果你非要用main作为入口，也不是不行，但那样你得自己处理C运行时的初始化，比如设置栈指针、初始化bss段。入门阶段完全没必要。我们可以约定：所有示例都写_start，需要返回退出码时直接调用exit系统调用，绕过C库。

4.2 循环累加：用cmp和b.le控制跳转

没有for循环关键字，汇编里的循环靠标签跳转。下面这段程序计算1加到10，结果放在x0里作为退出码。退出码最大255，55刚好合适。

// sum_loop.S — 1 加到 10，结果作为退出码 .text .global _start _start: mov x9, #1 // x9 是循环变量 i mov x10, #0 // x10 是累加结果 sum loop: cmp x9, #10 // 比较 i 和 10 b.gt done // i > 10 则跳出循环 add x10, x10, x9 // sum += i add x9, x9, #1 // i++ b loop // 跳回循环开头 done: mov x0, x10 // 退出码 = sum mov x8, #93 svc #0

这里用x9和x10而不是x0到x7，是为了和下一节的函数调用约定对齐。b.gt的跳转方向是向后跳转到done，这个标签在汇编阶段就被解析成指令偏移量。你可以改一下循环上限，比如加到100，然后观察退出码取模256后的值，这个实验对理解“退出码是byte类型”很有帮助。

4.3 函数调用：bl/ret与栈帧的16字节对齐

现实中的程序不会只用一个死循环，你需要函数调用。ARM64里bl指令负责两件事：把下一条指令地址存入x30，然后跳转到目标函数。ret则通过x30跳回调用处。

// func_call.S — 把累加逻辑封装成函数 .text .global _start _start: mov x0, #1 // 参数1：起始值 mov x1, #10 // 参数2：结束值 bl sum_range // 调用函数 mov x8, #93 // 用返回值作为退出码 svc #0 sum_range: stp x29, x30, [sp, #-16]! // 把栈指针往下挪16字节，保存fp和lr mov x29, sp // 设置帧指针 mov x9, x0 // x9 = start mov x10, #0 // sum = 0 loop: cmp x9, x1 b.gt done add x10, x10, x9 add x9, x9, #1 b loop done: mov x0, x10 // 返回值放x0 ldp x29, x30, [sp], #16 // 恢复fp和lr，同时把栈指针还原 ret

那个stp x29, x30, [sp, #-16]!是ARM64常见的函数序言写法：把两个64位寄存器一次性压栈，然后把sp往下挪16字节。!表示更新sp到新地址。结尾的ldp x29, x30, [sp], #16是反向操作。

为什么一定要压x30？因为sum_range里如果再调用其他函数，新的bl会把x30覆盖掉，不保存就无法正确返回。你看到的这套压栈、设帧指针、恢复、返回，就是所有编译型语言函数调用的底层模板。

4.4 参数怎么传、返回值怎么拿：AAPCS64调用约定速记

这部分用一张表就能讲明白。用到参数时，x0到x7按顺序对应第1到第8个参数；多余的参数会放到栈上。返回值放x0，如果函数返回128位的大结构，x0和x1拼起来用。

按照这张表，你在函数内部应该优先用x9到x15做临时变量，这样就不用费心保存恢复。如果临时变量超过7个再用x19到x28，但记得在入口处压栈，出口处恢复。

有一个细节新手经常忽略：sp在函数调用边界处必须是16字节对齐的。如果你在函数开头只压了一个8字节的寄存器，sp就成了非对齐状态，后续只要碰到ldp/stp指令就会触发对齐异常。这也是为什么函数序言里压栈的寄存器数量通常是偶数，比如两个一组压。

5. ARM汇编避坑指南：新手最容易翻车的五个细节

5.1 立即数越界：mov x0, #大数字开头就报错

现象：写mov x0, #0xFFFFFFFFFF，汇编器直接报错，提示立即数无效。

原因：ARM64的mov指令本质是movz的别名，它只在指令编码里留了16位给立即数，外加一个移位字段。所以你只能一条mov加载16位以内的值，想加载大常数必须换思路。

解决：用movz加movk组合，或者直接上伪指令ldr x0, =0xFFFFFFFFFF。后者会让汇编器自动把常量放进文字池，再用一条PC相对寻址加载，这是最简单省心的写法。不要试图硬背哪些立即数合法，直接把规则记成：超过16位的立即数一律用ldr。

5.2 两个内存操作数打架：add x0, [x1], [x2]为什么是非法的

现象：习惯x86的写法，想把两个内存里的数加起来，写了add x0, [x1], [x2]，汇编器报指令无效。

原因：ARM是load/store架构，算术指令只认寄存器，内存地址只能出现在ldr和str里。这是架构设计决定的，没有例外。

解决：改成先加载、再运算、再写回的三段式。

ldr x3, [x1] // 加载第一个内存值 ldr x4, [x2] // 加载第二个内存值 add x0, x3, x4 // 寄存器运算 str x0, [x5] // 需要的话再写回内存

这个坑的本质是思维惯性。每次写汇编之前，先问自己一句：这个操作数的内存访问是指令自己做的，还是需要先加载到寄存器？想清楚这个，一半的报错就消失了。

5.3 栈指针没还原：函数返回后直接崩在ret

现象：函数里压栈了x29和x30，但自己额外又压了一堆临时寄存器，返回之前只执行了ldp x29, x30, [sp], #16，然后ret，程序要么跳飞，要么第二次调用函数时数据全乱。

原因：栈是后进先出的，谁压的谁还原。你多压了几个寄存器，返回前就应该把这些额外占用的空间先释放，否则sp指向的位置不是当初入口处的栈帧，ldp从错误的位置恢复了x29和x30。

解决：压栈和恢复的配对要严格对称。多压一对就用ldp多恢复一对，恢复顺序和压栈顺序相反。实在拿不准，就在函数返回前用mov sp, x29把栈帧整个释放掉，这是编译器生成代码时最常用的手段。

5.4 拿x86的思维写ARM：源操作数和目的操作数顺序

现象：把x86的mov eax, 1的直觉搬过来，写成了mov #1, x0，报错。

原因：GNU as语法里，ARM指令的操作数顺序统一是“目标寄存器在前，源操作数在后”。add x0, x1, x2表示x0等于x1加x2，而不是x1等于x0加x2。

解决：每次写带三个操作数的指令之前，念一遍口诀：第一个是目的地。还有一个更隐蔽的关联陷阱：C语言里的a = b + c翻译成ARM汇编时，寄存器分配顺序是a在最左。参加过几次现场调试你就会发现，90%的“汇编怎么跟我想的完全相反”都出在这个点上。

5.5 字符串长度写错：write系统调用输出乱码甚至段错误

现象：write打印出来的内容除了预期文本，后面还跟着一长串乱七八糟的字符，甚至直接段错误。

原因：write的第三个参数是字节数。如果你用了sizeof的概念去数长度，或者字符串里有中文字符，就很容易多传或少传。多传一个字节，write就会多读一个字节，把数据段里相邻的内容连带打印出来。

解决：永远用汇编器的符号计算长度，不要在脑子里数格子。

msg: .ascii "Hello, ARM!\n" .equ len, . - msg

只要字符串内容一变，长度会自动跟着变，不会出现改文本忘改长度的尴尬。如果你把字符串放进了只读段，写错长度还不容易立刻暴露，等到调试别的功能时才被乱码干扰，那才叫血泪教训。

6. 用GDB把ARM汇编“看”明白：单步跟踪与反汇编验证

学汇编最怕的就是盯着源码脑补执行过程。GDB配合qemu的用户态调试模式，可以让你像看C程序一样单步走汇编，每走一步看一眼寄存器。启动调试的命令如下。

# 终端1：让qemu进入调试监听模式 qemu-aarch64 -L /usr/aarch64-linux-gnu -g 1234 ./hello # 终端2：启动gdb并连接 gdb-multiarch ./hello

进入gdb后依次执行下面的命令：

set architecture aarch64 target remote :1234 layout asm

layout asm会打开一个反汇编窗口，直接显示即将执行的指令，光这一条就值得单独为它配一套调试环境。接下来用si单步执行，每次只走一条指令，配合info registers x0 x1查看具体寄存器变化。

验证循环分支走向时，把断点打在循环条件的比较指令上。运行到断点后，每次用si跨过cmp和b.gt，重点观察PSTATE标志位的变化。你会在这一步亲眼看到Z位和N位怎么被置位，又怎么被b.gt消费掉，这是任何文档都替代不了的理解方式。

我刚学汇编时的习惯是：每写一个功能，先用objdump反汇编，再用GDB单步跑一遍，最后再改逻辑。现在处理复杂的启动代码时，也依然用这套流程，只是把qemu换成了JTAG调试器。这个方法最大的价值在于，你永远不用猜。遇到行为不符合预期，一条一条指令走，总能看到是哪一步开始跑偏的。

希望这套基于GDB的验证习惯能帮到你，让你在后续的汇编路上少走几个夜晚的弯路。

本文还有配套的精品资源，点击获取