前段时间有个同学拿了一段 C 代码来问我说他写的是a * 8把编译出来的汇编一看里面根本没有乘法指令变成了一条lea。他盯了半天没看明白问我是不是编译器偷偷改了逻辑。这个问题其实问到了根子上——很多人学完 C 语言脑子里只有语法和数据结构却对底下那层CPU 到底在执行什么完全没有概念。计算机系统基础里讲的常用机器指令补的就是这块空白它是编译器输出的最终形态是栈帧布局、性能调优、崩溃定位、安全分析全部要落脚的地方。接着前面几篇关于内存布局和寄存器约定的内容往下讲第 6 篇落到指令本身把常用的那一小撮拎出来讲透。这篇适合三类人刚学完 C、想知道编译器在背后干了什么的学生写代码时遇到过反汇编和源码对不上的在职开发者以及需要看懂崩溃现场、想建立底层直觉的人。读完你至少能做到两件事——把一段 C 反汇编出来逐条读懂以及知道什么时候该怀疑编译器把某条指令换掉了。1. 机器指令到底是什么一行 C 代码落到 CPU 的全部过程机器指令的本质是处理器和软件之间的一份合同。处理器对外承诺只要你在内存里摆上这样一串字节我就按这个语义去改寄存器、改内存、改标志位。指令集架构ISA就是这份合同的全文它规定了指令有多少条、每条多长、操作数从哪来、执行完哪些状态会变。x86-64 这份合同的特点是变长编码一条指令从 1 字节到 15 字节不等而 ARM、RISC-V 这类走的是定长路线几乎所有指令都是 4 字节。这个差别直接影响了你在反汇编里看到的东西——定长指令集里你可以按 4 字节一格去猜边界变长指令集里只能靠反汇编器老老实实从入口开始线性扫描。从抽象层次往下看一条 C 语句要变成 CPU 能执行的东西中间要过编译器前端语法树、类型检查、中端各种优化、后端指令选择、寄存器分配、调度最后输出汇编文本再交给汇编器编成机器码链接器把多个目标文件拼成一整个可执行文件。你在课程里听到的常用机器指令严格来说指的就是后端吐出来的那一层。这一层没有任何类型信息没有变量名只有寄存器编号和内存地址所以你看到的%rdi、0x8(%rsp)全都是裸的物理资源。1.1 指令就是操作码 操作数那点事拆开看任何一条指令都只回答两个问题干什么对谁干。前面那部分叫操作码后面那部分叫操作数。操作数有三种来源这是理解汇编的第一道门槛寄存器CPU 内部的高速存储数量有限、立即数直接写在指令里的常量、内存要通过地址去访存。x86-64 里这三种来源通过前缀区分得很清楚——寄存器带%立即数带$内存直接用括号表达式。比如movq $8, %rax是把常量 8 放进 rax而movq $8, (%rax)是往 rax 指向的那块内存写 8。一个字符的差别一个不访存一个访存性能差着量级。一条 x86 指令在字节层面最长可以拆成六段指令前缀、操作码、ModRM 字节、SIB 字节、位移、立即数。这六段不是每条都齐全缺哪段就省哪段。拿最常见的mov $0x10, %eax举例它的机器码是b8 10 00 00 00前面b8是把立即数送进 eax的操作码后面四个字节就是立即数本身。而mov $0x10, %rbx是bb 10 00 00 00只差一个字节——x86 给八个通用寄存器的这条指令各留了一个操作码。这种为了省一个字节而把寄存器编号编进操作码的设计是几十年兼容性妥协的结果也是 x86 指令长度从 1 到 15 字节不等的原因之一。搞嵌入式或者做逆向的人对这些字节编码很敏感做应用层开发的人只要知道有这回事就够了不用背。1.2 亲手把 C 编译成汇编看指令怎么来的光看理论没用最快的入门方式是直接看编译产物。准备一个最简单的函数别带任何头文件long scale_add(long a, long b) { return a * 8 b; }用gcc -O1 -S scale.c -o scale.s拿到汇编只看函数体部分大概是这样scale_add: leaq 0(,%rdi,8), %rax addq %rsi, %rax ret三行。第一行把参数 a在%rdi里乘 8 的结果放进%rax用的是lea而不是乘法指令第二行把 b在%rsi里加进去第三行返回。这里面有几个信息值得停下来想第一参数不是从内存里取的是直接躺在寄存器里因为 x86-64 的调用约定规定前六个整型参数依次放%rdi、%rsi、%rdx、%rcx、%r8、%r9第二返回值固定放%rax第三编译器主动把乘法换成了地址计算因为lea可以在一个周期内完成基址 变址 × 比例因子的运算比真正的imul快而且不占用乘法单元。把优化关掉再编一次-O0同一个函数会变成七八行参数先被存到栈上再从栈上读回来算完再写回栈。这就是为什么看汇编一定要看清楚编译选项——-O0的产物几乎全是把寄存器当临时变量用一遍再落栈拿它去分析性能或者理解编译器意图得到的结论基本都是错的。我个人的习惯是学指令阶段用-O1因为它优化得比较克制既不会把代码改得面目全非又能看出编译器的一些常规手法真要研究优化行为再用-O2。1.3 ATT 与 Intel 两种写法先选一种固定下来同一个mov在不同工具里长得完全不一样这是新手最容易晕的地方。ATT 语法开源工具链默认把源操作数写在前面、目的写在后面寄存器和立即数都带前缀movq %rsi, %rax。Intel 语法很多商业调试器、手册默认反过来目的在前源在后也不带前缀mov rax, rsi。两种写法表达的是同一条指令只是文本形式不同。我的建议很直接挑一种看熟它短期内不要来回换。国内高校的课程和大多数教材用 ATT 语法开源工具链默认也吐这个所以建议以 ATT 为主线。真需要切 Intel 语法objdump加-M intel就行不用重新学一遍指令。这里有个小技巧看到mov后面跟个后缀movb/movw/movl/movq基本可以确定是 ATT 语法看到movzx、movsxd、ptr这类词基本是 Intel 语法。切换语境的时候靠这几个标志词快速判断比逐字比对省事得多。注意网上搜到的很多汇编片段是 Intel 语法的直接复制到 ATT 环境里跑会报错甚至可能因为源目的颠倒而能编译但结果错。这类错误极难排查因为汇编器不会提醒你语义反了。2. 数据传送指令mov 家族的四个后缀和三种来源数据传送是整个指令集里出现频率最高的一类。程序里大量操作其实就是把数据从这里搬到那里真正的计算反而占比不高。mov 系列看起来简单但它的坑集中在两个地方位宽和后缀必须对齐以及某些组合在硬件层面根本不合法。2.1 位宽后缀对不上汇编器第一个不答应ATT 语法用四个字母后缀表示操作数宽度b是 1 字节8 位w是 2 字节16 位l是 4 字节32 位q是 8 字节64 位。这套后缀不是给汇编器看的装饰它直接决定生成哪条机器码。movb、movw、movl、movq在处理器里是四条完全不同的指令。麻烦在于源和目的的宽度必须一致。movq %rax, %ebx这种写法会直接被汇编器拒绝因为它一边是 8 字节一边是 4 字节。你可能会想那把小的放进大的不就行了——不行因为这里没有扩展的语义汇编器不会替你补高位。真要做扩展得用专门的movz零扩展或movs符号扩展系列。另一个容易踩的坑是 32 位写操作会顺手清零高 32 位。这是 x86-64 的一个特殊规定任何对 32 位寄存器的写操作都会把对应 64 位寄存器的高半部分清零。所以movl $0, %eax之后%rax整个都是 0。这条规则让编译器省了不少指令但也让很多人在读反汇编时产生我没改高 32 位啊怎么它没了的困惑。反过来的规则是对 16 位或 8 位寄存器的写操作不会清零高位movb $0, %al执行完%rax的高 56 位保持原样。这种不对称是硬件设计的历史包袱只能记下来。2.2 内存到内存不合法得靠寄存器过渡mov 的合法组合只有五种立即数到寄存器、立即数到内存、寄存器到寄存器、寄存器到内存、内存到寄存器。内存到内存不合法这是新手最常撞的墙。想把一个变量赋给另一个变量C 里一行就够汇编里必须拆成两步movq (%rsi), %rax movq %rax, (%rdi)中间那个%rax只是个中转站。这个限制不是随便定的是因为 x86 的 ModRM 编码格式里只有一个内存操作数槽位硬件没法在一条指令里同时给两个地址。所以后面你在看编译器产物时会发现很多看起来多余的 mov 其实就是中转不是编译器笨。内存操作数的写法是D(Rb, Ri, S)意思是基址寄存器 Rb 的值加上变址寄存器 Ri 乘以比例因子 S再加上位移 D。S 只能是 1、2、4、8 这四个值。举个例子数组访问arr[i]如果 arr 首地址在%rdi、i 在%rsi、元素是 8 字节的 long编译器会写成(%rdi, %rsi, 8)一条指令就把地址算完了。这个格式是 x86 里最实用的一个设计很多看起来编译器做了很多事的场合其实就是它在用这个格式省指令。寻址形式书写方式典型用途立即数寻址$0x10常量装入、常量比较寄存器寻址%rax寄存器间传递直接寻址0x404060访问全局变量间接寻址(%rax)指针解引用基址位移8(%rbp)访问局部变量、参数基址变址×比例(%rdi,%rsi,8)数组元素访问基址变址位移16(%rdi,%rsi,4)结构体数组字段访问2.3 movz 与 movs符号扩展决定程序对不对从窄类型转到宽类型时高位补什么是有讲究的。对于一个signed char提成int高位要补符号位对于unsigned char提成int高位要补 0。这两件事对应两条不同指令movs补符号位movz补 0。后缀还会叠加宽度像movzbl读作零扩展从字节到长字movslq是符号扩展从长字到四字。这个词读起来拗口但语义很明确第一个后缀是源宽度第二个是目的宽度前面的 z 或 s 表示补什么。movslq %eax, %rax就是把 eax 的 32 位按符号扩展成 64 位放进 rax如果 eax 是 0xFFFFFFFF扩展完是 0xFFFFFFFFFFFFFFFF也就是 -1而movl %eax, %eax等价于零扩展效果得到的是 0x00000000FFFFFFFF也就是 4294967295。同一个字节序列两种解释结果差了 42 亿。这种错误在真实项目里非常隐蔽——程序能跑大部分测试能过只有在边界数据上才炸。我踩过的一个具体场景是解析二进制协议。协议里某个长度字段是 1 字节无符号数代码里用char接收了然后当索引去访问数组。只要长度小于 128 都没事一旦超过 127 就被当成负数扩展出来是个巨大的负数接着就是一记段错误。查了很久才定位到是符号扩展的问题。经验是处理外部数据的字段一律用明确的无符号类型别让编译器替你做扩展判断。2.4 lea 不读内存它是编译器手里的计算器lea全称 load effective address字面意思是加载有效地址但它最常被用在完全不做内存访问的地方。关键点在于lea只做地址计算不真正去读那块内存。所以leaq 8(%rax), %rbx的语义是把 rax 的值加 8 放进 rbx跟内存里存了什么一点关系都没有。如果 rax 是 0这条指令也不会崩因为它压根没解引用。这个特性让编译器拿它当免费的算术器用。回到开头那个a * 8的例子leaq 0(,%rdi,8), %rax就是rdi 乘以 8不访问内存。更花哨的用法是乘非 2 的幂的常数n * 7可以写成(n 3) - n编译产物是leaq 0(,%rdi,8), %rax subq %rdi, %rax两拍就算完比imul $7, %rdi快因为 imul 延迟更高。n * 3、n * 5、n * 9都能这么玩。你如果自己动手写过优化器就会知道这类强度削弱是最基础也最效果显著的一类变换。但lea有边界比例因子只有 1、2、4、8 四个选择所以能一步搞定的乘法是常数 2、3、4、5、8、9 这一组其他常数就要组合好几条指令这时候编译器会退回去用 imul。如果你在反汇编里看到一串 lea、add、sub 组合在一起基本可以断定那是个乘以常数的操作。3. 算术与逻辑指令标志位才是真正的输出如果说 mov 解决数据在哪算术逻辑指令解决的就是数据怎么变。这里有个认知上的坎很多人以为add的结果就是那个和其实它有两个输出——结果写回目的操作数同时把一堆状态信息写进标志寄存器。后者才是控制流的基础第 4 节的跳转全靠它。3.1 add/sub 与四个常用标志位标志寄存器里有几个位是日常一定会打交道的ZF零标志结果为零时置 1、SF符号标志结果的最高位、CF进位标志无符号运算溢出、OF溢出标志有符号运算溢出。除此之外还有 PF、AF日常分析基本用不上可以先放着。理解这四个位要抓住同一份结果两种解释这个核心。比如0xFFFFFFFF 0x00000001如果当成 32 位无符号数看是 4294967295 1溢出CF 置 1如果当成有符号数看是 -1 1 0完全没有溢出OF 是 0ZF 置 1。同一次运算对有无符号的溢出判断完全不同这就是为什么汇编里跳转指令要分成有符号版本和无符号版本两套。sub的语义和add对称结果回写同时置标志位。减法在硬件里通常是用加补码实现的所以a - b实际算的是a (~b) 1这也解释了为什么sub和add的标志位规则能完全统一——它们本来就是同一套加法器的两种接线方式。3.2 inc/dec 的 CF 陷阱inc和dec是加减 1 的简写形式指令更短但有个非常隐蔽的性质它们不影响 CF。这个设计是有意为之为的是配合多精度算术——进位链需要在不被中间步骤打乱的情况下跨越多条加法。问题在于如果你写汇编时用inc代替add $1然后再去看 CF就会拿到一个完全无关的值。我见过一个用汇编写的多字节计数器的例子有人为了性能优化把所有的addq $1都换成了incq逻辑里恰好有一处是靠 CF 判断是否进位的结果在低字节从 0xFF 变成 0x00 的瞬间没有正确进位计数器在 255 到 256 的边界上卡住。这种 bug 出现的频率极低——每 256 次才触发一次——测了半天才复现。我的做法是在需要看 CF 的上下文里绝对不用 inc/dec。省下来的那点指令长度不值这个风险现代处理器的解码宽度足够多一个字节几乎不影响性能。3.3 imul 与移位乘以常数为什么不用乘法指令x86 的乘法有点特殊早期版本里单操作数的mul和imul隐含使用%rax或%al、%ax、%eax结果放进%rdx:%rax这样的双寄存器对因为两个 64 位数相乘的完整结果需要 128 位。这个双寄存器的用法在 64 位时代基本见不到了现在的编译器一般用双操作数形式imulq %rsi, %raxrax rax * rsi只保留低 64 位或者更少见的三操作数形式。但即使有 imul编译器也倾向于不用它。原因有三个一是乘法单元在现代处理器上延迟通常是 3 个周期而 lea、移位、加减都是 1 个周期能拆就拆二是乘法会占用执行端口可能和别的指令抢资源三是拆成移位加法之后编译器的调度空间更大。所以你在反汇编里看到的乘法里大概只有一小部分真的是imul。具体的替换规律值得记下来乘 2 的幂直接移位x * 4→shlq $2乘 2 的幂加减 1 用 lea 组合x * 7→(x 3) - x乘奇数且比较小的时候用移位加加减只有系数很大、或者表达式复杂到拆不动才真的用 imul。这套规则你在编译器优化相关的资料里都能找到详细版本但自己拿几个常数试一遍记得更牢。3.4 and/or/xor/not 与清零的三种写法逻辑指令按位操作没有进位借位规则比算术指令简单。and按位与、or按位或、xor按位异或、not按位取反。它们在代码里最常见的用途是掩码andq $0xF, %rax取低 4 位andq $-16, %rsp把栈指针对齐到 16 字节边界-16 的补码就是高 60 位全 1低 4 位全 0。有一个用法几乎所有二进制文件里都能看到xor %eax, %eax把 eax 清零。这条指令只有 2 字节31 c0而mov $0, %eax是 5 字节b8 00 00 00 00整整省了 3 个字节。更有意思的是xor在硬件层面还有一个额外好处——它被处理器识别为零化惯用法不需要读取寄存器的旧值直接产生结果。现代处理器甚至会把它优化到寄存器重命名阶段几乎零开销。所以不管从哪个角度看xor清零都比mov好编译器和手写汇编里都大量使用。不过xor清零有个衍生结果要注意它会把标志位改掉ZF 置 1。如果你后面紧接着一条依赖标志位的跳转就得多想一步。3.5 移位指令算术右移和逻辑右移不是一回事移位有三种shl左移、shr逻辑右移高位补 0、sar算术右移高位补符号位。左移两种等价右移分的这两种区别很大因为它们对负数处理方式不同-8 1用算术右移得到 -4用逻辑右移得到的是一个巨大的正数。C 语言里对负数右移的行为是实现定义的不同编译器可能给出不同结果所以在跨平台的代码里对负数做右移是明确的风险点。但编译器自己很懂这件事处理int除法时如果被除数可能为负它会用sar加一堆修正如果是unsigned类型直接一条shr就完事。你在反汇编里看到一段移位 加常数 移位的奇怪序列八成是在实现有符号除法向零取整的语义。移位量大于 1 的时候位数必须放在%cl里也就是 rcx 的低 8 位不能直接写任意寄存器。这是个硬件限制因为编码里只留了几个位给移位量。所以x nn 是变量会编译成先把 n 放进 ecx再shlq %cl, %rax。如果 n 是常数就不受这个限制直接编码在指令里。4. 控制转移指令跳与不跳全看标志位前面所有指令都是顺序执行靠%rip自动往下走。控制转移指令干的事就是改写%rip让程序去别的地方。这一节是理解 if、for、while、函数调用这些东西机器级形态的钥匙。4.1 条件跳转的有符号/无符号分水岭无条件跳转只有一条jmp想跳哪跳哪。条件跳转有一整族按判断条件分两组这是必须记清楚的部分判断条件有符号跳转无符号跳转判定依据相等jejeZF 1不等jnejneZF 0大于jgja有符号看 ZF0 且 SFOF无符号看 CF0 且 ZF0大于等于jgejae有符号看 SFOF无符号看 CF0小于jljb有符号看 SF≠OF无符号看 CF1小于等于jlejbe有符号看 ZF1 或 SF≠OF无符号看 CF1 或 ZF1这张表背下来比查资料快。关键记忆点是有符号那组看 SF 和 OF 的关系无符号那组看 CF。为什么因为有符号比较里溢出会翻转符号位的含义所以必须把 OF 拉进来修正无符号比较不涉及符号位进借位直接反映大小关系一条 CF 就够了。用错的后果很直接。C 语言里int a, b; if (a b)编译出来是jg而unsigned a, b; if (a b)编译出来是ja。如果有人手写汇编时把ja换成jg在正数范围内测试全都通过一旦碰到高位为 1 的数就全错——因为那时候它被当成负数了。这类 bug 在测试覆盖不足的代码里能潜伏很久。4.2 cmp 和 test 只算不存cmp和test是两条只出标志位、不留结果的特殊指令。cmpq %rsi, %rdi的语义是计算%rdi - %rsi按减法规则置标志位但不把结果写回%rdi。testq %rax, %rax是计算%rax %rax也就是它自己按与运算置标志位同样不写回。后面跟一条跳转就构成了条件判断 分支的标准形态。cmp最坑的地方是操作数顺序。ATT 语法里cmpq %rsi, %rdi算的是rdi - rsi不是rsi - rdi。这个顺序跟直觉相反因为源操作数在左边。我建议用一个固定口诀记cmp 的第二个操作数是被减数。或者换个角度记——cmp和sub的操作数位置完全一样subq %rsi, %rdi是rdi - rsicmpq %rsi, %rdi是判断rdi和rsi的关系方向一致。这样就不容易弄反。test的典型用途是判零和判符号。testq %rax, %rax之后接je就是rax 是否为 0接js就是rax 是否为负。和cmpq $0, %rax相比test编码更短而且不需要读立即数所以编译器优选它。判某个位是否置位也是test的活testb $0x80, %al之后看 ZF 就知道最高位是不是 1。4.3 if 与 for 在机器级的固定形态编译器把高层控制结构翻译成汇编用的是一套非常固定的模式几乎是公式化的。if-else 有两种译法取决于条件真假哪边更可能执行——编译器默认把不跳当作常态所以通常把 then 分支放前面条件取反后跳去 elsecmpq %rsi, %rdi jle .L_else # 如果 rdi rsi 就跳过 then 分支 # then 分支代码 jmp .L_end .L_else: # else 分支代码 .L_end:这种条件取反跳走的写法是为了让顺序执行的路径尽可能长减少跳转次数。现代处理器有分支预测跳转本身不一定慢但预测失败要清空流水线代价有十几个周期所以减少跳转仍然是优化方向。for 循环的翻译更典型几乎是把所有循环都归约成 while再把 while 归约成 goto 加 ifmovl $0, %eax # i 0 .L_loop: cmpl $10, %eax jge .L_done # if (i 10) goto done # 循环体 addl $1, %eax # i jmp .L_loop .L_done:看懂这个骨架之后你在反汇编里看到的任何循环都能往里套初始化、边界判断、循环体、步进。反过来如果想分析一段陌生二进制里的循环边界就找这几样东西基本一找一个准。4.4 call/ret 改变的是 %rip函数调用在机器层面就两条指令call和ret。call干两件事先把下一条指令的地址压到栈上这个地址叫返回地址然后跳到目标函数。ret干一件事从栈顶弹出返回地址写回%rip。就这么简单没有别的魔法。这解释了为什么函数调用必须用栈因为调用是嵌套的A 调 BB 调 CC 返回时要回 BB 返回时要回 A返回地址必须按后进先出的顺序管理栈天然就是这个结构。也解释了为什么栈溢出会导致程序崩溃——返回地址被覆盖了ret弹出来的就是垃圾值%rip跳到一片不该去的地方处理器立刻报错。call的机器码通常是e8加一个 4 字节的相对位移也就是说它跳转的目标是相对于当前%rip计算的不是绝对地址。这样做的好处是整个可执行文件可以加载到内存任意位置而不需要修改指令位置无关代码。你在反汇编里看到call 401136 printfplt这种是反汇编器帮你算好并标注了符号实际机器码里只有位移。5. 栈操作与函数调用现场还原栈是理解函数调用的基础而push/pop是操作栈的两条专用指令。把这两条指令的等价写法搞清楚很多栈帧上的困惑就自然消解了。5.1 push/pop 本质是两条指令pushq %rbx在语义上等价于subq $8, %rsp movq %rbx, (%rsp)popq %rbx等价于movq (%rsp), %rbx addq $8, %rsp注意栈的生长方向是从高地址往低地址所以压栈是减%rsp弹栈是加%rsp。这个设计在早期是为了让栈和堆能从内存两端相向生长谁越界就说明内存用完了。现在虽然地址空间大得多但这个方向约定一直保留着。为什么用push而不是手写两条指令一是编码短pushq %rbx只有 1 字节53二是处理器内部对 push/pop 有专门的优化比如栈引擎会把%rsp的更新和访存合并处理等效于零开销。所以即使语义上等价实际性能并不完全一样。push也能压立即数pushq $8但不能压 8 位立即数这个限制在写 shellcode 或者手写汇编时经常造成麻烦需要绕一下。5.2 一个非叶子函数的完整栈帧逐条拆解光看片段不够得看一个完整函数的开始和结束。下面这个函数有个局部数组和一次外部调用属于典型的非叶子函数必须建立完整栈帧long compute(long n) { long buf[4]; buf[0] n; return buf[0] * 2 helper(n); }-O0编出来的开头长这样compute: pushq %rbp # 保存调用者的 rbp movq %rsp, %rbp # 建立当前栈帧基址 subq $48, %rsp # 给局部变量留空间 movq %rdi, -40(%rbp) # 参数 n 存到栈上 ...逐条看。第一条pushq %rbp把调用者的帧基址保存下来因为%rbp是被调用者保存寄存器用完之后必须还原。第二条movq %rsp, %rbp把当前的栈顶设为新帧的基址此后所有局部变量都用-N(%rbp)这种相对负偏移访问好处是即使后面%rsp因为 push/pop 变动局部变量的位置也不会漂移——它们锚在%rbp上。第三条subq $48, %rsp一次性把栈顶往下挪给这块空间。那个 48 不是随便定的。局部数组buf[4]是 32 字节加上存参数需要的 8 字节再加上对齐要求。x86-64 的调用约定要求%rsp在每次call之前必须是 16 字节对齐而这个函数开头压了一个%rbp占了 8 字节所以总空间要凑到让%rsp落下 16 的整数倍。具体怎么算进入函数时%rsp对齐到 16push %rbp之后变成 8 mod 16再减 4848 是 16 的倍数还是 8 mod 16这就不对了——所以编译器实际上会减 40 或者 56。具体数字要看编译器但原则是让%rsp在 call 之前回到 16 字节对齐。这个细节在写汇编时经常被忽略然后调用某些库函数时莫名其妙崩溃因为那些库函数里用了需要对齐的 SIMD 指令。函数结尾是leave retleave是movq %rbp, %rsp; popq %rbp的简写作用是销毁当前栈帧、恢复调用者的%rbp。然后ret弹出返回地址。整个流程和开头严格对称这也是检查栈帧写没写错的方法——开头压了什么结尾就得按相反顺序弹什么。还有个小知识点如果一个函数不调用任何别的函数叶子函数现代编译器会直接省掉push %rbp和sub %rsp那一套改用红区——%rsp往下 128 字节的区域信号处理程序保证不会碰它所以叶子函数可以直接往那里写局部变量不需要调整%rsp。这就是为什么你在反汇编里会看到有些函数完全没有 sub rsp却依然在用-8(%rsp)这样的地址。看到这种写法不用怀疑是对的。5.3 寄存器使用约定表与调用者责任x86-64 把 16 个通用寄存器分成两组这个分组直接决定了函数调用时谁负责保存什么寄存器用途保存责任%rax返回值、临时计算调用者保存%rdi%rsi%rdx%rcx%r8%r9第 1-6 个整型参数调用者保存%r10%r11临时计算调用者保存%rbx%rbp%r12-%r15长期存储被调用者保存%rsp栈指针特殊必须还原调用者保存的意思是函数可以随便改这些寄存器不用跟谁打招呼所以调用者在call之前如果还有值要用得自己先存起来。被调用者保存的意思是函数如果要用这些寄存器必须先保存旧值返回前恢复原样。这个约定是性能优化的关键。编译器在做寄存器分配时会尽量把跨越函数调用的变量放进被调用者保存的寄存器这样就只需要保存一次而那些只在函数内部短命的值就扔进调用者保存的寄存器白嫖。你如果看反汇编发现某个函数一开头就把%rbx、%r12全 push 一遍说明它被分配了不少长生命周期变量不是乱写的。5.4 从 %rip 视角看一次完整调用把这些串起来一次compute(5)的调用过程大致是调用者把 5 放进%rdi执行call compute处理器把返回地址压栈、跳到 compute 入口compute 保存%rbp、建栈帧、把 5 存进局部变量、调helper又一次 call/ret、算结果放进%rax、leave、ret回到调用者%rax里就是返回值。整个过程里唯一跨函数传递的东西就是栈和寄存器没有任何隐藏通道。理解到这一层你就明白为什么函数调用的开销主要来自保存/恢复现场也就明白为什么内联能省掉这笔开销——内联本质上是把call/ret和栈帧管理整个删掉把函数体直接铺在调用点。6. 反汇编实操与常见问题排查前面讲的是读懂这一节讲怎么自己动手看和看到的东西为什么和你预期不一样。这部分才是真正拉开差距的地方因为书上讲的都是理想情况实际环境里的问题往往来自编译选项、优化级别和工具默认行为。6.1 反汇编看指令的三板斧第一条路是编译期看汇编gcc -S -O1 foo.c得到的是编译器的原始输出带注释和符号名最容易读。缺点是它不经过汇编器跟最终机器码可能有细微差别比如跳转距离的优化。第二条路是目标文件反汇编objdump -d foo.o。这能让你看到实际的机器码字节加反汇编文本两边对照着看对理解指令编码很有帮助。加--no-show-raw-insn可以只看文本加-M intel换成 Intel 语法。第三条路是运行期调试gdb里用disassemble看函数x/10i $pc看当前位置往后 10 条指令info registers看所有寄存器stepi单步执行一条机器指令注意是机器指令不是源码行。调试崩溃时最有用的是x/i $pc——程序停在信号上的时候这一条命令直接告诉你崩在哪条指令上配合info registers就能看出是哪个地址访问出了问题。提示gdb里stepi和nexti的区别是前者会进入 call后者会跳过 call 直接到返回。分析陌生代码时先用nexti快速过一遍骨架再回到关心的位置用stepi细看。6.2 明明写了却没生成的指令去哪了这是最常见的困惑源码里明明有个乘法反汇编里找不到imul明明有个if找不到跳转。原因基本都在优化上。第一类是常量折叠。int x 3 * 4;直接变成int x 12连指令都没有。第二类是强度削弱就是前面讲的乘法变移位和 lea。第三类是死代码消除算出来没人用的东西全删掉。第四类是公共子表达式消除同一个表达式只算一次。第五类是循环不变量外提循环里每次都不变的计算挪到外面。想看清原始对应关系就得关优化-O0。但-O0出来的代码又长又啰嗦主要价值是建立源码-指令的对应直觉不适合用来分析性能。我的建议是两个都看先-O0确认自己写的每一句对应哪些指令再-O1看编译器做了什么变换对照着理解优化器的思路。这个过程比读任何优化相关的资料都有效。还有一类特殊情况是编译器用了库函数的内联版本或者内建函数builtin比如strlen在常数参数下直接被算成常量memcpy小尺寸时直接展开成几条 mov。看到莫名其妙的 mov 序列先想想是不是某个库调用被内联展开了。6.3 段错误定位从 %rip 反查段错误SIGSEGV本质上只有两种成因访问了没映射的地址或者访问了没有权限的地址比如往只读段写。定位过程是固定的几步先btbacktrace看调用栈找到自己代码的那一帧再frame N切过去然后x/i $pc看崩在哪条指令接着info registers看所有寄存器的值重点看指令里用到的那个地址寄存器最后p $_siginfo._sifields._sigfault.si_addr拿到触发故障的具体地址。拿到地址之后判断如果是 0 或者很小的数比如 0x8基本是空指针解引用加了偏移如果是 0x5f5e10 这种看起来像 ASCII 的值八成是把数据当指针用了如果是 0x7fff 开头的可能在栈上越界了如果是很大的随机数可能是野指针或者未初始化变量。有了这个流程之后绝大多数段错误在五分钟内能定位到行。真正难的是内存踩踏——错误发生在别处崩溃点只是受害者。这种情况需要用地址检查工具跑一遍或者用watch监视可疑地址的写入。6.4 常见问题速查表现象常见原因排查方法反汇编里找不到预期的乘法指令编译器把乘法替换成 lea 或移位用-O0对比或搜索 lea 组合汇编器报operand size mismatchmov 后缀位宽和操作数不匹配检查 b/w/l/q 与寄存器/内存宽度手写汇编调用库函数后崩溃栈未按 16 字节对齐在 call 前确认%rsp是 16 的倍数大小比较结果不对但正数测试全过有符号用了 ja/jb 或反之检查 jg/jl 与 ja/jb 的选用多字节加法进位丢失用了 inc/dec 导致 CF 被保留改用addq $132 位运算后高 32 位莫名变 0x86-64 对 32 位写入的清零规则需要保留高位时改用 16 位或 8 位操作局部变量地址在函数调用后改变用了%rsp相对寻址而非%rbp检查栈帧建立方式或改用编译器默认输出负数右移结果异常逻辑右移与算术右移混用有符号用 sar无符号用 shr我自己练这块的方法比较土找几个小函数分别用-O0和-O2编出来逐行对着源码做标注把每条指令对应到哪句 C 上。刚开始很慢一个二十行的函数要花一小时但做了十几个之后速度会快得离谱——因为常用指令就那么几十条模式就那么十几种见多了就成了直觉。后来再有同事拿着崩溃现场来问我看一眼寄存器就能猜个八九不离十靠的全是这段时间的手感。另一个习惯是每次遇到编译器把我代码改了的情况就记一笔写清楚源码、优化级别、生成的指令、为什么这么改。这个笔记积累到三五十条之后你对编译器的判断力会明显不一样——看到一段代码大概能预料出它会变成什么样子。这比背指令表有用得多因为指令表查一下就有而编译器会怎么想这件事只能靠喂样本养出来。
