ARM汇编基础教程：R15、CPSR与栈帧调试避坑指南

简介：《ARM汇编基础教程1》面向准备进入ARM平台开发、底层调试或逆向工程的学习者，系统梳理汇编语言入门所需的核心概念，帮助读者建立处理器版本、指令集与代码兼容性之间的整体认识。压缩包内共1个docx文档，大小约2.65MB，以章节化文档笔记组织内容，便于按主题阅读和查阅。文档围绕ARM汇编与链接流程、字半字字节及有符号无符号数据类型、大小端字节序、R0至R15与CPSR等寄存器展开，并说明R0至R3传参、SP管理栈空间、LR保存返回地址、PC指向指令流等函数调用约定；同时给出扩展阅读线索，可衔接后续内存读写、条件分支、栈与函数等主题。已有211人学习，适合作为ARM汇编入门的第一份系统笔记，也便于开发与安全方向读者查漏补缺。

1. 第一次跟 ARM 汇编基础教程，我在调试器里被 R15 教育了

源码里刚执行完mov r0, pc，R0 里躺着的是当前指令地址加 8，而调试窗口显示的 PC 却是当前指令地址。当时我以为是调试器坏了，后来才明白是三级流水线在起作用。整套 ARM 汇编基础教程里，这种“文档一句话、调试两小时”的点至少还有五六个：as和ld的两步链、R11 的两个身份、Thumb 下BX目标地址的最低位、push之后 SP 到底减了多少、函数返回时lr去了哪。这篇不逐条翻译教程目录，而是按我实际走完的顺序，把每个知识点拆成“为什么这么设计、怎么在调试器里亲眼看见、哪里最容易翻车”，新手能照着跑，写过一阵子裸机代码却说不清 CPSR 那几位的人，也能挑到判断依据。

2. 构建链与版本对齐：先让 .s 变成一个能跑的目标文件

2.1 as 和 ld 各干了什么，为什么我不建议一上来就用 gcc 一键编译

教程里给的两行命令很短，但每一步的产物值得看清楚。as负责把汇编文本翻译成机器码，同时留下符号表和重定位信息；ld负责把这些碎片按地址拼起来，解析跨文件的符号引用。中间那个.o不是半成品垃圾，它是你排查“符号未定义”“地址错位”的第一手材料。

# 汇编：.s -> .o；-g 保留调试信息，GDB 里才能按源码行下断点 as -g program.s -o program.o # 链接：.o -> 可执行文件；-e 显式指定入口符号，避免链接器自己猜起点 ld program.o -o program -e _start # 验证产物：反汇编看指令编码，符号表看地址分配 objdump -d program readelf -s program

三个参数值得单独说。-g不是可选项，是必需品，没有它你在 GDB 里只能对着地址猜；-e _start解决的是“链接器默认入口可能不是你写的第一条指令”这个隐性问题，裸链接时尤其明显；objdump -d输出里每一行左边是地址、中间是机器码、右边是助记符，这三列对照着看，你才能确认自己写的mov r0, #2到底被编成了几个字节。

至于 gcc 驱动，它会在你不知情的情况下塞进启动文件、C 运行库、默认链接脚本。基础阶段出问题时，你分不清是自己写错了还是启动代码没配对，排查成本直接翻倍。我的做法是：先用as+ld把最小可执行文件跑通，确认工具链、目标架构、端序都对了，再换成 gcc 驱动去写带 C 的混合程序。

提示：交叉工具链的前缀按你的目标填，把as、ld、objdump换成带前缀的版本即可，命令行为一致。

2.2 处理器版本和指令集版本不是一回事

这是最容易混的一层。芯片型号是芯片型号，架构版本是架构版本，指令集状态又是另一层。同一个架构版本号下，能用的编码集合可能差出一大截。我按手头接触过的几类目标整理了一张对照，具体细节仍要以对应版本的参考手册为准。

表里最值得盯的是 ARMv7-M 那一行。这类内核只跑 Thumb 态，你从别处抄来的一段纯 ARM 编码放进去，链接可能不报错，运行直接跑飞，而且现象非常“玄学”——它不一定在第一条指令崩，可能跑到第三条才出事。判断方法很土但有效：反汇编出来看指令长度，全是 2 字节或 4 字节交错的基本就是 Thumb，整齐 4 字节的是 ARM 态。

2.3 把目标信息写进文件头注释，是给自己留的后悔药

我现在的每个.s文件开头都固定四行注释，格式如下。别小看这个习惯，半年后回来改一段十六进制常量，第一件要确认的事就是“这套编码当时是按哪个架构、哪种端序编的”。

@ program.s @ target : ARMv7-A, AArch32, little-endian @ abi : AAPCS, 参数走 R0-R3 @ build : as -g program.s -o program.o && ld program.o -o program -e _start @ note : 本文件全部为 ARM 态编码，不要直接丢进只跑 Thumb 的内核

这四行不是形式主义。target那一行决定了你能不能用条件执行、能不能用桶形移位器；abi那一行决定了你写函数时参数往哪放；build那一行决定你三个月后还能不能一键重建；note那一行是专门写给未来的自己看的警告。血泪经验是：真正让人翻车的往往不是难的知识点，而是当时觉得“这么简单不用记”的上下文。

2.4 端序：别等到读内存时才想起来还有这回事

教程里提到端序由程序状态寄存器的 E 位控制，这一句很容易被略过，直到你在调试器里看到内存窗口的字节顺序和预期完全相反。ARMv6 之后，取指是固定小端，数据访问可以按 E 位切换。也就是说，同一颗核上，指令流和数据流的端序策略是可以不一致的。

@ 假设 r2 指向一块已初始化的内存，内容是 11 22 33 44（按字节递增写入） ldr r0, [r2] @ 小端下 r0 = 0x44332211；大端下 r0 = 0x11223344 ldrh r1, [r2] @ 读半字，小端下 r1 = 0x2211 ldrb r3, [r2, #1] @ 读第二个字节，r3 = 0x22，这一步和端序无关

ldr一次读 4 字节，ldrh读 2 字节，ldrb读 1 字节，字节级读取天然不受端序影响，这是排查端序问题时最可靠的一把尺子。我的习惯是：一旦怀疑端序错了，先ldrb逐字节读出来，和内存窗口比对，确认无误后再换成ldr，这样能立刻定位问题出在端序还是出在地址算错。地址算错的表现和端序错很像，都是“值不对”，但原因完全是两码事。

3. 寄存器与状态位：把 R0-R15 和 CPSR 画成自己的一张图

3.1 R0-R15 的分工，以及三个最常被误用的位置

教程里给的划分是 R0-R11 通用、R12 是内部程序调用寄存器、R13 是栈指针、R14 是链接寄存器、R15 是程序计数器。光记住名字没用，得知道每个位置在什么场景下会被“别人”改掉。我整理成下面这张表，最后一列是我实际踩过的误用。

R11 那一行需要单独展开。教程里明确说了它有两个身份：作为栈帧指针帮助追踪栈帧边界，同时在系统调用发生时存储系统调用号。这两件事在小函数里几乎不会冲突，但在你自己手写带系统调用的裸函数时，就得小心别在 prologue 之前把它拿去存别的值。

R12 这一行更隐蔽。它是链接器在生成跳转时用的临时寄存器，意味着它的值在两次函数调用之间没有任何保证。我见过一段代码把循环计数放在 R12 里，短距离跑得好好的，加了几个函数调用之后计数莫名其妙跳变，查了半天才发现是这个原因。

3.2 数据类型后缀：一个字、半字、字节，各自的扩展规则

教程里给的后缀规则很精炼：半字是-h，有符号半字-sh，字节-b，有符号字节-sb，字没有扩展。关键不在于背后缀，而在于理解“扩展”这个动作本身——从内存读到寄存器是 32 位目标，小尺寸数据必须被拉宽，拉宽时高位补什么，就是有符号和无符号的区别。

@ 假设 r2 指向的内存字节内容为 0xFF ldrb r0, [r2] @ 无符号字节：高位补 0，r0 = 0x000000FF ldrsb r1, [r2] @ 有符号字节：按符号位扩展，r1 = 0xFFFFFFFF @ 假设 r2 指向的半字内容为 0x8000 ldrh r3, [r2] @ 无符号半字：r3 = 0x00008000 ldrsh r4, [r2] @ 有符号半字：r4 = 0xFFFF8000

这段代码最有价值的地方是它能让你亲眼看见“同一个内存值，两种读法，结果天差地别”。0xFF当无符号字节是 255，当有符号字节是 -1；0x8000当无符号半字是 32768，当有符号半字是 -32768。写解析协议字段、读传感器原始值时，选错后缀不会报错，只会静默算错，这种错误最难查。

存储方向同理。strb只写 1 字节，strh写 2 字节，str写 4 字节。这里有个连锁坑：用strb写完之后立刻用ldr读同一地址，读到的是“1 字节新值 + 3 字节旧值”拼出来的东西，看起来像乱码，其实是完全正确的行为。

3.3 CPSR 的 N/Z/C/V/E/T/M，用一条 cmp 全跑一遍

教程里给了完整的位含义表，其中 N、Z、C、V 分别对应 x86 的 SF、ZF、CF、OF。这四位是条件执行和循环的基础，光看表记不住，必须自己跑一遍让它动起来。

C 位那条最容易绕晕：加法有进位置 1，减法有借位则置 0、无借位则置 1。方向反了，后面所有基于bcc/bcs的分支都会错。

.text .global main main: mov r1, #1 mov r2, #2 cmp r1, r2 @ 1 - 2 = -1，结果为负，N 位置 1 cmp r2, r1 @ 2 - 1 = 1，无借位，C 位置 1 cmp r2, r2 @ 2 - 2 = 0，Z 位置 1，同时 C 位置 1 bx lr

cmp做的是隐式减法，只改 CPSR，不改参与运算的寄存器。三段比较分别验证了 N、C、Z 三个标志位，实际调试时在三次cmp之后各下一次断点，看 CPSR 的值变化，比读十遍表都管用。教程里特意强调“用于比较的寄存器的值不会改变”，这句是给从高级语言过来的人打的预防针——cmp不是赋值，它只留下状态。

V 位单独说一句。它表示溢出，判定标准是结果超出 32 位补码范围，比如两个大正数相加得到负数。日常写代码很少直接看 V，但做漏洞分析、构造边界输入时，V 位往往是判断“这个值是不是被当成有符号数处理了”的关键证据。

4. 指令集与函数帧：ARM/Thumb 切换、条件执行与栈的真实动作

4.1 ARM 和 Thumb 是两套编码，不是两种运行模式

教程里这句话如果只看一遍很容易滑过去：ARM 和 Thumb 是两种工作状态，和运行模式没有任何关系，ARM 态和 Thumb 态的代码都可以跑在用户模式下。工作状态说的是“指令怎么编码”，运行模式说的是“当前处于什么特权级”。把这两层混在一起，后面所有关于切换的讨论都会乱。

编码差异直接影响你能写什么。ARM 态指令固定 32 位，所有指令都支持条件执行；Thumb 态基础指令 16 位，条件执行要靠it指令在部分版本上模拟，桶形移位器这种“一条指令顺带做移位”的能力也是 ARM 态特有的。教程里点出了一个很实际的取舍：写利用代码时倾向用 16 位 Thumb 指令，因为 32 位编码里太容易出现\0字节，字符串处理函数会在那里截断。

我的判断标准更朴素：目标设备如果只跑 Thumb 态，那就从第一天起全部按 Thumb 写，不要写一半 ARM 再想办法转；如果目标允许两种状态，核心逻辑用 ARM 态写，需要塞进受限空间的那一小段单独用 Thumb 写。混着写不是不行，但每切一次都要在注释里标清楚，否则调试时你会怀疑人生。

4.2 指令模板和第二操作数：桶形移位器省下的那条指令

教程给的指令模板是“助记符 + S 扩展位 + 执行条件 + 目的寄存器 + 第一操作数 + 第二操作数”，并且明确说了只有部分指令用满所有域。这个模板的价值在于它解释了 ARM 汇编为什么看起来比 x86 短——很多操作被压缩进了一条指令里。

第二操作数的几种形式值得背下来：立即数#123、寄存器Rx、算术右移Rx, ASR n、逻辑左移Rx, LSL n、逻辑右移Rx, LSR n、循环右移Rx, ROR n、带扩展的循环右移一位Rx, RRX。配合桶形移位器，可以做到下面这种压缩。

@ 目标：把 r0 乘以 2 存进 r1 @ 笨办法：两条指令 mov r1, r0 add r1, r1, r1 @ 老手写法：一条指令，移位器直接参与 mov r1, r0, lsl #1

第二条写法里，lsl #1是在数据通路上顺手完成的，不额外占用一个指令周期，也不占用一个临时寄存器。这类压缩在写紧凑循环、手写小型解码器时很实用。判断依据也简单：只要你的第二操作数是一个“寄存器 + 固定移位量”，优先考虑塞进同一条指令，而不是拆成两步。拆开写不是错，但在指令条数敏感的场景里，差的就是这几十个字节。

4.3 状态切换：BX、BLX 和最低有效位那一位

教程里给的切换条件是：用bx或blx跳转，并且把目标寄存器的最低有效位置 1。位为 1 切到 Thumb，为 0 保持 ARM。处理器在取指时会忽略最低位，所以不用担心对齐问题。

@ 假设 thumb_func 是 Thumb 态函数的起始地址 ldr r0, =thumb_func add r0, r0, #1 @ 最低位置 1，声明目标是 Thumb 态 bx r0 @ 跳过去，同时完成状态切换 @ 返回时同理，lr 的最低位已经带上了正确的状态标记 bx lr

这段代码里最反直觉的是add r0, r0, #1。看起来像地址算错，实际上这一位是给处理器看的“状态标记”，不是地址的一部分。判断自己有没有踩这个坑有个很直接的现象：跳转过去之后第一条指令就崩，反汇编窗口显示的指令和你写的对不上，八成就是最低位没设或者设反了。

blx和bx的区别在于blx会先把返回地址写进lr。写非叶函数的间接调用时，用blx能省掉手动保存lr的一步，但也意味着你必须在调用前确保lr里的旧值已经被保存过，否则返回地址就彻底丢了。

4.4 栈的四种实现，和 push/pop 到底做了什么

教程把栈讲得很细：push和pop是一系列内存指令的别名，不是真实指令。这句话改变了我读反汇编的方式。栈的实现分两个维度——SP 指向最后压入的项叫 full，指向下一个空槽叫 empty；压栈时地址减小叫 descending，增大叫 ascending。四个组合，教材里常见的是 full descending。

关键结论是：push {r0}在 full descending 下的实际动作是“SP 先减 4，再把 r0 写到新 SP 指向的地址”。教程里的例子给出了完整的地址变化：SP 从0xfffefac0变成0xfffefabc，pop {r0}再把 SP 加回0xfffefac0，同时把0xfffefabc处的 4 字节读进 r0。

.text .global main main: mov r0, #2 push {r0} @ SP 减 4，把 r0 的 2 写入新栈顶 mov r0, #3 @ 只改 r0，SP 不动 pop {r0} @ 从栈顶读回 2 写入 r0，SP 加 4 bx lr

单步走这段代码，重点看三个时刻：执行push前 SP 是多少、执行后 SP 是多少、栈顶那 4 个字节变成了什么。很多人第一次看会觉得“mov r0, #3之后栈里的值也变了”，其实没有，变的是寄存器不是内存。反过来，push之后如果内存窗口没刷新，你会以为压栈失败，实际上是显示没更新。

还有一个容易被忽略的点：push {r0-r3}这种多寄存器写法，压栈顺序是按寄存器编号来的，最终内存里的布局是 r0 在高地址、r3 在低地址。pop的顺序正好相反，这样才能一一对应地还原。

4.5 函数三段式：prologue、body、epilogue 与叶函数的差别

教程把函数拆成 prologue、body、epilogue 三段，并且给了具体写法。这三段的分工是：prologue 保存现场并开辟栈空间，body 干活并把结果放进 R0，epilogue 恢复现场并跳回调用点。

.text .global main @ 非叶函数示例：调用了 max func: push {r11, lr} @ prologue 开始：保存帧指针和返回地址 add r11, sp, #0 @ 把栈帧底部固定在当前位置 sub sp, sp, #16 @ 为局部变量开辟 16 字节 mov r0, #1 mov r1, #2 bl max @ body：调用另一个函数，结果在 r0 sub sp, r11, #0 @ epilogue：把 SP 恢复到栈帧底部 pop {r11, pc} @ 恢复帧指针，把返回地址弹进 PC

几个细节值得逐一对照。push {r11, lr}一次压两个寄存器，SP 减 8，顺序上 r11 在低地址还是高地址取决于具体实现，但pop {r11, pc}的对称写法保证能正确还原。add r11, sp, #0看起来像没用的加法，其实是把当前 SP 固定成栈帧基点，后面所有局部变量都相对于 R11 定位，而不是相对于会变化的 SP。sub sp, sp, #16是真正开辟空间的那一步，16 字节的具体大小按局部变量需求调整。

epilogue 里的sub sp, r11, #0是把 SP 拉回栈帧底部，这一步的作用是“不管 body 里把 SP 弄成什么样，我都能准确回到原位”。然后pop {r11, pc}一次性完成两件事：恢复帧指针，并把之前保存的返回地址直接弹进 PC，跳回调用点。

叶函数不需要这一整套。叶函数本身不调用别的函数，lr不会被覆盖，所以可以省掉压栈和恢复。

@ 叶函数：不调用其他函数，直接算完返回 leaf_max: cmp r0, r1 movlt r0, r1 bx lr

cmp加条件执行movlt就完成了取较大值，全程没有碰栈。这也是 ARM 条件执行带来的实际收益：一个分支判断被压成了一条条件移动，省掉一次跳转。什么时候用叶函数写法、什么时候必须写完整三段式，判断依据就是“这个函数里有没有bl或blx”。有，就必须保存lr；没有，就能省。

参数传递规则也在这层体现。前四个参数走 R0-R3，超过四个的部分放栈上；返回值放 R0，64 位返回值用 R0 和 R1 组合。这条规则决定了你写函数时头部不需要额外声明，调用双方约定好即可。

5. 避坑与排查：五条让我在调试器前坐了两小时的问题

5.1 读到 PC 比预期大 8

现象：执行mov r0, pc之后，R0 里的值比当前指令地址大 8，而调试窗口显示的 PC 还是当前指令地址。

原因：ARM 是三级流水线，取指、解码、执行用的不同硬件部件，取指阶段 PC 已经走到了前面的位置，ARM 态下两条指令 8 字节。调试器为了展示更符合逻辑，把 PC 显示成了“当前执行指令地址”。

解决：记住这个偏移量，写位置无关代码或者计算相对偏移时按 +8 算（Thumb 态常见是 +4）。调试器里看到 PC 和执行地址不一致时，先问自己“这是显示值还是真实值”，不要急着怀疑工具链。

5.2 push 之后看内存，栈顶值像是没变

现象：执行push {r0}，SP 确实减了 4，但内存窗口里那个地址的值和压之前一样，看起来压了个寂寞。

原因：内存窗口没有刷新，或者你看的地址算错了。另外小端下 4 字节值的显示顺序是从低到高，0x00000002在内存里显示成02 00 00 00，如果你按大端习惯去读，会觉得值完全不对。

解决：压栈后手动刷新视图，并且用ldrb逐字节读一遍对照。养成“先用字节读，再用字读”的顺序，能同时排除刷新问题和端序问题。

5.3 Thumb 下 bx 跳过去第一条指令就崩

现象：目标地址确认是对的，bx执行完直接异常，反汇编窗口显示的指令和源文件对不上。

原因：目标寄存器最低位没置 1，处理器按 ARM 态去解码 Thumb 编码，自然全是错。或者反过来，明明是 ARM 态函数却置了 1。

解决：跳转前先打印目标地址的二进制最低位，确认是 0 还是 1。写代码时把“取函数地址 + 置位”封装成一个固定写法，别每次手写add #1，手写次数越多出错概率越高。

5.4 函数返回后跑飞，栈看起来是平衡的

现象：函数执行完，pop也执行了，SP 回到了调用前的位置，但程序跳到了一个完全无关的地址。

原因：非叶函数里没有保存lr就调用了下一个函数，返回地址被覆盖。SP 平衡不代表lr没被改，这两件事完全独立。

解决：检查函数体里有没有bl或blx。有，就必须在 prologue 里保存lr，在 epilogue 里从栈上恢复。用pop {r11, pc}而不是pop {r11, lr}再bx lr，能少一条指令，也更不容易写错。

5.5 第五个参数死活传不进去

现象：函数按四个参数写没问题，加到第五个参数，被调函数读到的值完全不对。

原因：前四个参数走 R0-R3，第五个开始走栈，而且压栈时要考虑栈的对齐要求。直接把第五个参数塞进 R4 是无效的，被调函数根本不会去那里找。

解决：把第五个参数按约定压到栈上，位置要在调用前算好。一个实用习惯是：参数超过四个时，先用push把多余参数按逆序压栈，调用完再调整 SP 恢复。另外注意 SP 的对齐，某些 ABI 要求调用点 SP 是 8 字节对齐，不对齐时可能不报错但行为诡异。

6. 收尾：用一段最小代码把 PC 偏移和标志位一次验证完

学完这套基础教程，我留下的最有用的习惯是一个十分钟能跑完的自检脚本。它只做两件事：确认 PC 偏移量，确认标志位方向。这两件事一旦搞反，后面写多少代码都是白费。

.text .global _start _start: mov r0, pc @ 把 PC 值取出来，用于验证流水线偏移 mov r1, #1 mov r2, #2 cmp r1, r2 @ 1 - 2 = -1，预期 N = 1 cmp r2, r1 @ 2 - 1 = 1，预期 C = 1，N = 0 cmp r2, r2 @ 2 - 2 = 0，预期 Z = 1，C = 1 b .

汇编、链接、进调试器，三件事按顺序做：第一，在mov r0, pc之后看 R0 和 PC 的差值，ARM 态应该是 8，Thumb 态常见是 4；第二，在三次cmp之后分别看 CPSR 的 N、C、Z 位，确认减法无借位时 C 是 1 而不是 0；第三，把mov r0, pc换成mov r0, pc加一条空指令，看偏移量是否随指令位置移动，验证你对流水线的理解不是死记硬背。

我第一次跑这段时，C 位方向记反了，导致后面一个循环的退出条件永远不成立，程序在调试器里“看起来在正常跑”，实际是死循环。那次之后我形成了一个强制习惯：凡是写条件分支，先在纸上把“哪个标志位、置 1 还是置 0、跳还是不跳”这三件事写清楚，再动手敲。这个习惯救回来的时间，远超写那几行字的成本。

这套 ARM 汇编基础教程的好处是七篇之间有递进关系，从寄存器、指令集一路铺到栈和函数帧，每篇都能单独跑起来验证。想跟着走一遍的话，从第一篇开始按顺序做，每篇结束时把当篇涉及的寄存器状态和标志位亲手在调试器里看一遍，比连着读完七篇有用得多。希望帮到你。

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