常用机器指令实战：从mov、lea到栈帧与函数调用

第一次把一段 C 代码丢进反汇编器，看到满屏的mov、lea、jmp时，多数人会有种被糊弄的感觉：这些助记符长得都差不多，凭什么它们就决定了一段程序的全部行为？在计算机系统基础这门课里，"常用机器指令"往往被安排在数据表示之后、链接与存储层次之前，位置很尴尬——前面刚啃完补码和浮点编码，脑子还没缓过来，后面又要进入地址空间和缓存，于是这一讲常常被当成"背指令表"糊弄过去。但恰恰是这一章，是后面所有内容的地基：不理解mov的宽度语义，就解释不了整数溢出；不理解cmp设置的条件码，就看不懂编译器把if变成了什么；不理解call和ret之间的隐式契约，栈溢出、段错误、返回地址被覆盖这类崩溃就永远只能靠猜。我写这一篇，是想把机器指令从"考试条目"还原成"能上手验证的东西"——常用机器指令到底有哪几类、每一类在真实编译产物里长什么样、哪些细节是课本一笔带过但实际会咬人的。不管你是刚学完数据表示、准备做 bomblab 那类实验的学生，还是工作几年后想回头补一补底层的开发者，下面这些内容都可以直接照着敲一遍验证。

1. 机器指令不是"另一种语言"，而是处理器能执行的最小动作集

1.1 从"一条指令"到底由什么构成说起

很多人对机器指令的第一印象是那串十六进制数字，觉得它神秘。其实拆开看非常朴素：一条机器指令就是"操作码 + 若干操作数"，操作码告诉处理器"做什么动作"，操作数告诉它"对谁做"。操作数一共有三种来源——寄存器、内存地址、立即数（写死在指令里的常量）。就这么三种，没有第四种。所谓汇编语言，不过是给每个操作码起了个能读的助记符，把寄存器编号换成%rax这样的名字，把内存寻址换成了8(%rdi,%rsi,4)这样的表达式。处理器眼里没有mov这个词，只有一串比特；汇编器做的事就是把人类能读的文本翻译回那串比特。

理解了这一点，很多困惑会自然消解。比如为什么同一个"赋值"操作，有时候编译出来是一条mov，有时候是三条？因为源和目标的组合不同——寄存器到寄存器、立即数到寄存器、内存到寄存器，这几种是处理器直接支持的；而内存到内存，硬件根本不提供这条指令，编译器只能拆成"内存读到寄存器，寄存器再写回内存"两步。这不是编译器笨，而是指令集设计时的取舍：内存到内存的传输需要两次访存，硬件上要么加一条慢指令，要么让软件拆开，主流架构都选了后者。

1.2 变长编码与定长编码：两种设计哲学带来的实际差异

指令集大致分两派。一派是变长编码，指令长度从 1 字节到十几个字节不等，好处是编码密度高、常用指令可以编得很短，代价是取指和译码复杂，处理器内部要花不少功夫判断"这条指令到哪儿结束"。另一派是定长编码，每条指令固定 4 字节，取指简单、流水线友好，代价是代码体积偏大，而且立即数字段往往放不下完整的 64 位常量，需要用多条指令拼。

这个差异对写代码的人不是纯理论。你在变长架构上看到的反汇编，push %rbp只占 1 个字节，mov %rsp,%rbp占 3 个字节；而在定长架构上，这两条各占 4 字节。当你做缓冲区溢出那类实验、需要精确数出"覆盖到返回地址要写多少个字节"时，指令长度就是硬指标，靠猜是猜不出来的，必须用反汇编工具逐条数。我见过不少人在这一步翻车：明明算好了偏移，运行时却偏移了几个字节，最后发现是某条mov的编码长度记错了。这类问题唯一的解法就是打开反汇编，一条一条看。

1.3 真正需要记住的指令其实不到三十条

课程讲义往往列一张几十行的指令表，看着吓人。但如果你去统计编译器实际生成的汇编，会发现高频指令非常集中：数据传送就mov一家独大，算术逻辑主要是add、sub、imul、and、or、xor、lea、cmp、test，控制流就是jmp、各类条件跳转、call、ret，栈操作push、pop。剩下的一大堆（比如各种字符串操作指令、位操作扩展指令）在普通代码里出现频率极低，用到再查就行。

所以我给的建议是：把这二十几条练到"看到就知道它改了什么、设置了哪些标志位"的程度，剩下的建立索引意识即可。下面几节就按数据传送、算术逻辑、控制流、函数调用这四条主线展开，每一条我都给出真实编译产物里的样子，你可以对着自己机器上的编译器逐条验证。

2. 数据传送指令：mov 家族里藏着三个容易翻车的点

2.1 宽度后缀不是装饰，它决定了指令动多少字节

mov这个助记符后面常跟一个字母后缀：b表示字节（8 位）、w表示字（16 位）、l表示双字（32 位）、q表示四字（64 位）。movb、movw、movl、movq是四条不同的指令，编码不同，行为也不同。初学者最容易犯的错是觉得"反正都是搬数据，写哪个都行"，结果搬了 4 个字节却按 8 个字节去读，高 4 字节是垃圾数据，数值直接错得离谱。

这张表要背下来，因为它直接对应 C 语言的类型宽度。当你看到movl %edi, %eax，就应该立刻反应过来：这是在处理一个 32 位整数，而不是 64 位。注意寄存器名字的变化——%rax的低 32 位叫%eax，低 16 位叫%ax，最低 8 位叫%al。它们不是不同的寄存器，而是同一个物理寄存器被切成了不同宽度的"窗口"。

2.2 写 32 位寄存器会顺手清掉高 32 位

这条规则课本上讲得轻描淡写，实际影响巨大：在 64 位架构上，任何写入 32 位寄存器的指令，都会自动把该寄存器的高 32 位清零。这意味着movl $0, %eax和movq $0, %rax效果相同，但前者编码更短，所以编译器清空一个 64 位寄存器时，往往故意写成 32 位形式。

反过来，写 16 位或 8 位寄存器不会清零高位，只改那一小段，剩下的位保持原样。这是一个极容易埋雷的地方。比如你写了一段内联汇编，用%bl改了一个字节，然后按%rbx去读，读到的值里混着%rbx原来的高 56 位。这种 bug 的症状非常诡异：数值时对时错，取决于那个寄存器此前被谁用过。我的排查习惯是，只要怀疑寄存器高位有脏数据，就在可疑指令前后各下一次断点，用info registers把整个 64 位值打出来对照，通常一两轮就能定位。

2.3 符号扩展与零扩展：char 转 int 为什么会出负数

把窄类型转成宽类型时，必须决定"新补出来的高位填什么"。无符号数填 0，这叫零扩展；有符号数要填符号位，这叫符号扩展。对应的指令是movz系列和movs系列，后面跟两个后缀表示"从多宽扩展到多宽"，比如movzbl是从字节零扩展到双字，movsbl是从字节符号扩展到双字。在 64 位场景下，把 32 位有符号数扩展到 64 位用的是movslq。

这里有个非常经典的翻车场景：C 语言里char c = -1; int i = c;得到的是-1，而unsigned char c = 255; int i = c;得到的是255。看上去理所当然，但如果你手写汇编时用错了扩展指令，把该符号扩展的地方用了零扩展，结果就是-1变成了255。更隐蔽的是，有些代码在char的符号性上存在平台差异，同一个表达式在不同架构上结果不同，根源就在这里。

2.4 内存寻址：那对括号里能塞下多少东西

完整的内存操作数写法是偏移(基址寄存器, 变址寄存器, 比例因子)，实际地址 = 基址 + 变址 × 比例 + 偏移。比例因子只能是 1、2、4、8 四个值，不能是 3 或 5。这个限制让很多人第一次见时觉得奇怪，其实原因很朴素：硬件在做地址计算时就是拿变址寄存器的值左移 0、1、2、3 位，移位是免费的，乘以 3 需要一次加法，电路上就不划算了。

恰好 C 语言里数组元素的大小基本都是 1、2、4、8 字节，所以这个限制几乎不影响表达力。访问long数组的第i个元素，编译出来就是一条movq (%rdi,%rsi,8), %rax——一条指令完成"取基址、算下标、乘元素大小、访存"四件事。这也是为什么处理器的寻址模式设计得这么"贴心"：它就是照着高级语言的访存模式倒推出来的。

还有个小细节值得动手验证：小端序。你在 C 里写int x = 0x11223344;，然后在调试器里用x/4xb &x逐字节看内存，会得到44 33 22 11，低字节在前。这个观察看起来无聊，但它是理解"用指针强转类型然后读出来的值为什么和预期不符"的关键，也是缓冲区溢出实验里构造攻击载荷时必须要考虑的顺序问题。

3. 算术与逻辑指令：add、lea 和条件码之间的微妙关系

3.1 二地址指令的"目的操作数既是输入又是输出"

add %rsi, %rdi这条指令的语义是%rdi = %rdi + %rsi。源操作数在前，目的操作数在后，结果写回目的操作数。这和数学里a + b = c的三元形式不同，是典型的二地址设计：省一个操作数字段，代价是原值被覆盖。所以编译器在做c = a + b时，必须先把a复制到c所在的寄存器，再执行add，这也解释了为什么简单的一行加法有时候会编译出两条指令。

顺带说一个语法坑：不同汇编语法下操作数顺序是相反的。一种语法写成"源, 目的"，另一种写成"目的, 源"。反汇编工具默认用前者的居多，而你在网上搜到的示例代码经常是后者，直接照抄会得到完全相反的结果。我的做法是固定一套语法，在笔记里标注清楚，读别人代码时先看开头几行判断风格，别急着理解语义。

3.2 lea 不是访存指令，它是披着访存外衣的加法器

lea的全称是"加载有效地址"，字面意思是把括号里算出来的地址装进寄存器，而不去访问那个地址。这个设计初衷是为了配合指针运算，但它有个副作用极其好用：因为地址计算电路本来就是做加法和移位的，所以lea可以当成一个"不设置标志位的多操作数加法器"来用。

举个例子，leaq (%rdi,%rsi,4), %rax一条指令就算出了rdi + rsi*4，如果用add和移位来实现，起码要三条。再比如乘以 3、5、9 这类常数，编译器特别喜欢用lea：leaq (%rdi,%rdi,2), %rax就是乘 3，leaq (%rdi,%rdi,4), %rax就是乘 5。你读优化后的汇编时，看到一堆lea却找不到任何内存访问，别慌，那是编译器在拿它做快速算术。

lea和add的关键区别在于：lea不改任何条件码。这在编译器做指令调度时很有价值——如果一段代码后面紧跟着一个依赖条件码的条件跳转，那么在中间插入add会破坏标志位，插入lea则安全。知道这一点，你就能理解为什么有些看起来"绕远路"的代码反而更快。

3.3 条件码：一次减法顺带产出的四个副产品

算术逻辑指令在算出结果的同时，还会顺手更新一组标志位，常用的有四个：进位标志 CF（无符号溢出）、零标志 ZF（结果为零）、符号标志 SF（结果为负）、溢出标志 OF（有符号溢出）。这四个位就是后续条件跳转的全部依据。

理解条件码的关键是搞清楚"谁设置的"。add、sub、and、or、xor、test、cmp都会设置，lea、mov、push、pop不会。而cmp本质就是一次不做保存的减法：cmp %rsi, %rdi计算%rdi - %rsi，只更新标志位，不写回结果。同理test %rax, %rax是做一次与运算，只更新标志位，专门用来判断某个值是否为零。

这张表的实际价值在于：写错有符号版本和无符号版本，代码在大部分输入下都能跑对，只在边界值上出错。比如用jb（无符号小于）去比较两个可能为负的整数，-1会被当成一个非常大的正数，判断结果完全相反。这类 bug 藏得极深，测试用例只要不覆盖负数就发现不了。我的一般做法是，看到涉及大小比较的汇编，先在纸上写下对应的 C 表达式，确认两边符号性一致，再往下读。

3.4 乘除法为什么要占用一对寄存器

imul有两种形式。双操作数形式imulq %rsi, %rdi直接把乘积写进%rdi，只保留低 64 位，溢出部分被丢弃。单操作数形式imulq %rsi则把%rax和%rsi相乘，结果放进%rdx:%rax这个 128 位的组合里，高位在%rdx，低位在%rax。为什么这么设计？因为两个 64 位数相乘，结果最多需要 128 位才能完整装下，硬件必须提供两个目标寄存器。编译器在只需要低 64 位时会选双操作数形式，因为它更快、寄存器压力更小。

除法更麻烦。idivq %rsi的语义是用%rdx:%rax这个 128 位数除以%rsi，商放%rax，余数放%rdx。也就是说，在做除法之前，你必须先把%rax符号扩展到%rdx:%rax，用cqto这条指令完成。忘了这一步，%rdx里是上一轮遗留的垃圾值，除出来的商会被放大到一个离谱的数字。这是手写汇编时最高频的错误之一，而且症状很典型：程序不崩溃，只是结果莫名其妙地大。

除法还有两个硬性约束。一是除数不能为零，否则处理器直接抛异常，程序收到算术异常信号后终止；二是有符号除法在"最小负数除以 -1"时会溢出，因为结果无法用同宽度的有符号数表示。编译器在优化除法时非常谨慎，通常会把除以常数转换成乘法和移位，因为除法指令动辄几十个时钟周期，而乘加只要几个。你在优化后的汇编里看到imul和shr组合，多半就是编译器在做这个替换。

4. 控制流指令：cmp 加 jcc 撑起了所有分支

4.1 if 语句被翻译成的那个固定套路

C 里的if (a > b) { x = 1; } else { x = 2; }，编译出来大致是：先cmp比较，再一条条件跳转跳到 else 分支，然后顺序执行 then 分支的代码，最后一条无条件跳转越过 else 分支。注意这个结构——条件跳转的目标是 else 分支，而不是 then 分支。这个反直觉的排列方式是有讲究的：它让"条件成立"这条最常走的路径变成顺序执行，不需要跳转，对处理器的分支预测和取指流水线更友好。

所以你在读汇编时，看到jg .L2这样的指令，不要下意识认为.L2就是 then 分支。更可靠的做法是找标签位置：标签出现在哪里，哪里就是跳转目标。我通常会在纸上把标签和对应的 C 代码块标出来，画一遍控制流，再回头理解逻辑，比硬读快得多。

4.2 循环的三种形态与编译器偏爱的那一种

while循环的标准翻译是：先跳到条件判断处，判断为假就跳出，为真则执行循环体，执行完跳回判断处。这个结构每次迭代要做两次跳转（一次条件跳转回判断，一次条件跳转跳出）。而do-while形态是：先执行循环体，再判断是否继续，每次迭代只需要一次条件跳转。

差异看起来很小，但循环是热点代码，跑几百万次后差距就出来了。所以编译器在做循环优化时，经常把while改写成"先判断一次，然后进入 do-while 形态"，这个技术叫循环旋转。你在优化后的汇编里看到循环体在条件判断之前，别以为是编译器搞错了顺序，那是它主动做的变换。手动展开循环、把判断提到外面，也是同样的思路——减少跳转次数，让处理器少做无用功。

4.3 switch 为什么有时候会变成一次间接跳转

switch的翻译策略取决于 case 值的分布。如果 case 值稀疏、跨度很大，编译器会生成一串cmp加条件跳转，本质上退化成了 if-else 链。但如果 case 值密集（比如连续的 0 到 7），编译器会在只读数据段里放一张地址表，然后这样干：先把 switch 的值减去最小值，检查是否越界（越界就跳到 default），再用jmp *表基址(,%rax,8)一次跳到对应位置。

这条间接跳转指令是理解跳转表的关键：它从内存里读出一个地址，然后跳过去。好处是无论有多少个 case，分发只需要常数时间；代价是处理器难以预测跳转目标，分支预测失败率上升。这也是为什么有些安全场景会特意检查 switch 的边界——如果越界检查被优化掉或者写错了，攻击者就能用一个超大的下标从地址表里读出任意地址并跳过去。防御手段很直接：确保下标在跳转前做过无符号比较，且表本身放在只读段。

4.4 call 和 ret 之间的那份隐式契约

call做的事有两件：把下一条指令的地址（返回地址）压到栈上，然后跳到目标函数。ret做的事只有一件：从栈顶弹出返回地址，跳过去。就这么简单，但所有函数调用、递归、栈回溯都建立在这个基础上。

这份契约的脆弱之处在于：返回地址就放在栈上，和局部变量、缓冲区挨在一起。只要有一处越界写，返回地址就可能被覆盖，ret一跳就跳到不知道哪去了。症状是程序在一个和源码毫无关系的地方崩溃，调用栈看上去完全错乱。遇到这种崩溃，我的排查顺序是：先看崩溃地址是否像个正常代码地址（如果是0x41414141这种，基本可以确定是被可控数据覆盖了），再看崩溃时的栈指针是否合理，最后用调试器打印栈顶若干字，找返回地址应该在的位置。

还有一个实际写代码时会遇到的约束：调用发生时，栈指针必须满足 16 字节对齐。原因是某些向量指令要求操作数地址对齐，编译器为了保证函数内部的对齐要求，就规定了调用边界上的对齐规则。如果你手写汇编或者做内联汇编时破坏了这个约定，程序可能在某些指令上直接崩掉，报的错还和执行的具体指令有关，非常难查。我踩过一次，症状是调用某个库函数时崩在一条movaps上，查了很久才发现是自己压栈时少压或多压了 8 个字节。

5. 栈帧与函数调用：参数到底是怎么传过去的

5.1 push 和 pop 省下的不只是一个字节

push %rbp等价于"栈指针减 8，然后把%rbp写到新栈指针处"，pop %rbp是反过来。为什么不直接用sub加mov？因为push的编码只有 1 个字节，而sub加mov加起来要 7 个字节左右。在变长编码架构上，这个差距对代码体积影响不小，所以编译器优先用push。

函数的开场白（序言）通常是这样的三步：push %rbp保存调用者的栈基址，mov %rsp,%rbp建立当前帧的基址，sub $N,%rsp为局部变量腾空间。收尾时是mov %rbp,%rsp或leave（等价于mov %rbp,%rsp加pop %rbp），然后ret。这个套路叫帧指针链，它的价值在于调试：每个函数的%rbp指向上一帧的%rbp，串起来就是一条完整的调用链，调试器和性能分析工具靠它做栈回溯。

不过现代编译器在优化模式下经常省略帧指针（对应"省略帧指针"的编译选项），因为%rbp也是一个通用寄存器，省下来能给热点代码多用一两个变量。代价是栈回溯变难，只能靠额外的调试信息表来恢复。这也是为什么你在优化后的汇编里找不到push %rbp，别以为函数没有栈帧，它只是不用帧指针来索引局部变量，改用栈指针加固定偏移。

5.2 前六个整型参数走寄存器，多出来的走栈

参数传递规则是 ABI 定死的，主流 64 位平台的约定大致如下：

"调用者保存"和"被调用者保存"这两列是很多人第一次看会懵的地方。它的实际含义是责任划分：调用者保存的寄存器，被调用函数可以随便改，调用者如果还要用原来的值，就得自己在调用前存好；被调用者保存的寄存器，函数如果想用，必须先把原值压栈，返回前恢复。这样划分的目的是减少不必要的保存动作——只在真正有冲突时才付代价。

超过六个的参数从右往左压栈，第七个参数在调用前位于栈顶附近。这里有个容易算错的地方：压栈顺序是从右往左，所以第一个栈上参数反而在最低地址。手写汇编传参时算错偏移，函数读到的参数就全乱套了，而且不会报错，只是算出来的结果离谱。

5.3 一个完整例子：从 C 到汇编逐行对照

拿一个最简单的函数做验证：

long add3(long a, long b, long c) { return a + b + c; }

用优化等级 1 编译并输出汇编：

gcc -O1 -S -o add3.s add3.c cat add3.s

得到的核心部分大致是这样：

add3: leaq (%rdi,%rsi), %rax addq %rdx, %rax ret

对照着看就很清楚了：%rdi是a，%rsi是b，%rdx是c，返回值放%rax。第一条lea算出a+b放进%rax，第二条add把c加上去。整个过程没有一次访存，也没有栈帧——参数全在寄存器里，函数体足够简单，连栈都不用碰。这就是"叶子函数"的典型形态。

如果你把优化等级改成 0 再编译一次，会看到完全不同的结果：参数被一个个从寄存器搬到栈上，加法从栈里读数再做，最后再搬回%rax。多出来的那十几条mov全是栈搬运，对理解逻辑毫无帮助。所以我一直建议：读汇编用优化等级 1 或 2，别用 0。等级 0 的产物是给调试器用的，不是给人读的。

5.4 想看机器码长什么样，用反汇编而不是看源码

从 C 源码到可执行文件之间隔了好几层，想看清楚每一步，我常用的组合是三步：

gcc -O1 -c -o add3.o add3.c # 生成目标文件 objdump -d add3.o # 反汇编，看机器码和汇编的对照 objdump -d -M intel add3.o # 换成另一种汇编语法

objdump -d的输出左边是机器码字节，右边是对应的汇编。对着看几遍，你会对"一条指令占几个字节"建立直觉，也会明白为什么某些指令编码特别短——因为它们被设计成最常用的形态，享受了编码上的优待。

6. 一套可复现的验证流程：三步把任意 C 语句翻译成指令

6.1 第一步：把语句削到最小

想搞清楚某个语法结构编译成什么，最有效的方法不是读文档，而是做减法。写一个只包含目标语句的函数，参数用简单类型，不要有全局变量、不要有函数调用、不要有复杂的类型转换。比如想搞明白数组下标访问，就写：

long get(long *p, long i) { return p[i]; }

编译出来是一条movq (%rdi,%rsi,8), %rax。整个映射关系一目了然：指针在%rdi，下标在%rsi，元素大小 8 体现在比例因子上。如果一上来就写一个带三层嵌套循环、还调用其他函数的版本，你会在几十条指令里迷失方向。

6.2 第二步：对照反汇编确认，别相信"我以为"

写完最小例子，一定要实际编译出来看，不能靠记忆推断。我见过太多次"我觉得应该是这样"，结果编译器因为别名分析、常量折叠或者指令选择策略，生成了完全不同的东西。比如你写x * 2，可能得到add %rax,%rax，也可能是shl $1,%rax，还可能是lea (%rax,%rax),%rax——三种写法语义相同，编译器选哪个取决于上下文和寄存器压力。

这一步的产出应该是：一条 C 语句对应哪几条指令、每条指令读写哪些寄存器、改不改标志位。把这三点写进笔记，比抄十页指令表有用。

6.3 第三步：在调试器里单步，看寄存器和内存的真实变化

静态看汇编只能看到"应该发生什么"，动态单步才能看到"实际发生了什么"。把程序编译成带调试信息的可执行文件，在调试器里下断点，用stepi逐条执行，每执行一条就打印一次寄存器和关键内存。

gcc -O0 -g -o demo demo.c gdb ./demo # 在调试器内： # break main # run # display/i $pc 当前指令 # info registers 所有寄存器 # x/4xb &var 按字节看内存 # stepi 执行一条机器指令

有个细节要注意：优化等级 0 的时候，源码行和机器指令基本一一对应，单步很舒服；但一旦开了优化，一条源码行可能对应好几条指令，甚至顺序被打乱，单步就很难跟。所以我一般用等级 0 做"逐条观察"，用等级 1 或 2 做"看优化效果"，两种场景分开。

6.4 常见编译选项该怎么选

这几个选项我几乎是肌肉记忆了。特别提一句，如果你只想要一份干净的汇编文本，加上去掉展开表的选项能让输出少掉一大半无关内容，读起来清爽很多。

7. 那些让程序"活着但算错了"的指令级陷阱

7.1 陷阱一：有符号和无符号的跳转指令用反了

这是最高频也最难查的一类错误。用jb去比较负数，-1被当成一个极大正数，判断结果完全颠倒；反过来用jl去比较两个指针或者无符号长度，超过某一阈值后也会出错。麻烦在于，正常输入下两种写法结果一致，只有边界值才暴露。

排查方法很笨但有效：找到对应的cmp和跳转指令，回到 C 源码确认两边操作数的类型，如果有一边是无符号类型（包括size_t、指针差值、unsigned变体），就必须用无符号版本的跳转。有个容易忽略的点是：数组长度、循环计数器如果是size_t，那整个比较链都应该是无符号语义，编译器通常会正确生成，但你手写内联汇编时很容易顺手写成有符号版本。

7.2 陷阱二：除法前忘了扩展高位

前面提过，idiv用的是%rdx:%rax这个 128 位被除数，使用前必须用cqto做符号扩展。漏掉这一步，%rdx里是上一次运算留下的值，商会被放大成几万倍甚至更多。我排查过一次类似问题，症状是某个统计值偶尔会大得离谱，但代码复现率极低，最后定位到一段手写汇编在做除法前少了一条扩展指令，而%rdx的值取决于前一分支走了哪条路径，所以才"偶尔"出错。

7.3 陷阱三：把 lea 的括号当成内存访问

新手写内联汇编时经常把lea和mov搞混：以为leaq (%rdi), %rax是"把%rdi指向的内容读进%rax"，实际上它只是把%rdi的值复制过去。这个误解会导致后续所有访存都错位。区分方法很简单：mov带括号表示访存，lea带括号永远不访存。看到lea就直接按算术表达式去理解，别去想内存。

7.4 陷阱四：栈对齐被破坏后的诡异崩溃

函数调用边界要求栈指针 16 字节对齐。破坏它的原因通常有两种：手写汇编时push/pop数量不配对，或者调用前手动调整了栈指针却没调回来。症状是崩溃在一个和业务逻辑无关的地方，比如某条向量加载指令，错误信息还可能是"段错误"而不是"对齐错误"，因为有些平台把对齐违规也报成访存异常。

排查方法：在崩溃点之前下断点，打印栈指针，看它模 16 的结果是不是 8（进入函数体时的正常状态）。如果不是，往上追溯是谁动了栈指针。我一般会在可疑的call前后各打印一次栈指针，两者差值应该是 8 的整数倍且符合预期。

7.5 陷阱五：把 32 位寄存器当 64 位用

前面说过写 32 位会清零高位，反过来，读 64 位的时候如果只写了低 32 位，高 32 位可能是零也可能是旧值，取决于之前发生过什么。这种 bug 的可怕之处在于它依赖执行历史，同一段代码在不同调用路径下结果不同，用简单用例根本测不出来。

我的经验是：只要在汇编里看到%e开头的寄存器和%r开头的混用，就要多留个心眼，确认类型宽度是有意为之而不是顺手写错。尤其注意指针运算，指针永远是 64 位，用 32 位寄存器算指针偏移，超出 4GB 地址空间就会静默截断。

7.6 关于学习路径的一点个人体会

我带的几批新人里，学得快的那几个有个共同点：他们不背指令表，而是拿一段自己写的、结果可预测的小 C 程序，编译、反汇编、单步，然后把每一条指令和源码行对应起来，做成自己的笔记。这个过程一开始很慢，一条语句要折腾十几分钟，但做过二三十个例子之后，再看陌生的反汇编就有感觉了——不是记住了每个助记符，而是形成了"这种模式通常对应什么源码结构"的直觉。

反过来，那些抱着指令表和教材硬背的，考试能过，但真让他看一段优化后的汇编找 bug，基本无从下手。机器指令这东西，本质上是处理器暴露给你的一层接口，接口文档写得再全，不亲手调几次也不会用。所以我一直建议：找一个能生成反汇编的工具链，挑十段你熟悉的 C 代码，从简单的赋值、分支、循环，到数组访问、结构体访问、函数调用，全部跑一遍。这十段代码覆盖了绝大多数日常场景，做完之后，这一章就不再是需要背的知识点，而是能用的工具了。