汇编语言与计算机系统结构这门课，真正让人卡住的往往不是指令语法，而是第一次上机时对完整流程没有概念。我见过不少同学，在编辑器里写好了汇编源文件，却不知道接下来该敲什么命令，也不知道每个命令到底做了什么。这篇笔记就来聊一个最简单的上机过程示例：从编写一份 .asm 源文件开始，经过汇编、链接，再到用调试器逐条观察指令。整条链路走通之后，你后面做任何实验都会顺手很多，尤其是当成系统结构课程的底层基础来用。

1. 上机前为什么要先搞懂"四个阶段"

1.1 "汇编"这个词，新手最容易搞混

上课时老师随口说"你先汇编一下"，新手很容易懵：汇编不是语言吗，怎么变成动作了？但在这个语境里，"汇编"指调用汇编器，把汇编语言源文件转换成目标文件的过程。类似地，"编译"指把 C 语言源文件转换成目标文件或可执行文件。中文术语的动词化，算是第一道坎。

我建议把所有操作拆成：编辑、汇编、链接、运行调试。每一阶段都会产出一个你能拿在手里的文件：编辑阶段得到 .asm 文本文件；汇编阶段得到 .o 目标文件；链接阶段得到可执行文件；运行调试阶段看到进程在操作系统里的表现。这四个产物分别在什么环节检查，是上机最该建立的心智模型。

可以打个比方：你有一份菜谱，但不代表菜已经上桌。汇编相当于把菜谱里的步骤翻译成后厨能执行的切配动作；链接相当于把切好的食材按顺序拼成完整菜品；加载运行才是真正开火。哪个环节出了问题，表现都不同，排查思路也不同。

1.2 每个阶段的输入输出和检查手段

先看编辑阶段。输入是你的想法，输出是 .asm。这个阶段没有"程序能否运行"的概念，只有文本内容是否符合汇编语法。最容易犯的错误是用了中文标点、文件保存成了带 BOM 的 UTF-8 编码、行尾是 CRLF。NASM 对这类问题比较敏感。检查手段很简单：用 cat、less 或编辑器打开源码看，就能发现大部分问题。

汇编阶段。输入 .asm，输出 .o。汇编器逐行读入，把每条指令翻译成机器码，同时建立符号表。符号表是什么？简单说就是"变量名和标签名在目标文件里的记录"，比如 msg、_start。此时程序还不能运行，因为地址还没有被最终确定。同一个 msg 符号，可能被多个模块引用，汇编器需要把这些信息留给链接器处理。

链接阶段。输入一个或多个 .o，输出可执行文件。链接器主要做这几件事：合并相同 section、解析符号引用、分配虚拟地址、记录入口点。所以链接器报错多是"找不到符号""重复定义"。你会发现，汇编阶段顺利通过的程序，在链接阶段同样可能失败。

运行调试阶段。你在 shell 里执行一个名为 hello 的程序时，操作系统加载器读取可执行文件头，把代码段和数据段映射到虚拟内存，设置好栈，然后跳到入口地址。现代操作系统下，程序不会直接碰硬件，而是通过 syscall 请求内核输出。这正好是系统结构课后面重点讲的用户态与内核态。

1.3 为什么课上非要安排"上机"

有人觉得汇编语法过时，没必要花时间。但上机不是学"怎么打字"，而是把寄存器、内存地址、栈偏移这些抽象概念变成可观察的东西。你在 C 语言里写一句 return 0，编译器帮你处理了退出码；在汇编里，你得自己决定用哪条系统调用，有没有把返回值放到正确寄存器。这个"亲手操控细节"的过程，对建立系统结构的直觉非常关键。

举个例子，C 语言函数调用时，栈帧的建立和销毁，如果你只用高级语言看，永远只是图；但当你用汇编单步调试，看到 rsp 在 call 前后变化，看到返回地址被压栈，这些概念就真正落地了。上机示例虽然简单，却包含了后续复杂实验的全部骨架。

2. 环境准备：我用的工具链与为什么这样选

2.1 主流工具链选型对比

我推荐的组合是 Linux 下的 NASM 加 ld 加 GDB。原因很简单：NASM 使用 Intel 语法，和大多数教材中的 8086 汇编写法接近；ld 足够轻量，能让你看清链接器到底做了什么；GDB 则是观察寄存器和内存的最佳工具。

有些同学习惯 Windows 下的 MASM 加 DOSBox，好处是贴近 8086 真实模式，能用到 INT 21H 这类 DOS 中断，坏处是环境老、调试手段弱，而且很多语法细节与现代系统不兼容。macOS 也能装 NASM，但它的系统调用号和参数传递方式与 Linux 不同，跑课内示例前要单独适配。

如果你跟着这门课做实验，我的建议是别折腾多重组合，选定一套主环境，把精力放在流程和原理上。

2.2 安装与验证

如果你用的是 Ubuntu 或 Debian 系，安装就三条命令：

sudo apt update sudo apt install -y nasm gdb binutils

安装完之后，务必确认版本号能正常打印：

nasm -v ld --version gdb --version

binutils 是一个非常关键的包，它包含 ld、objdump、readelf 等全套二进制工具。后面检查目标文件格式、反汇编、查看符号表全靠它。GDB 可能系统已经自带，但明确定位到版本会让你心里有底。

Windows 用户建议装一个 Linux 虚拟机或使用 WSL，尽量获得原生命令行体验。这一步不需要纠结版本新旧，略新即可。真正重要的是后面的命令流程。

2.3 源文件书写的基本规范

动手之前，先把源文件的格式规范说清楚，可以省掉后面一半的报错。第一，文件名以 .asm 结尾。第二，推荐 UTF-8 无 BOM 编码、LF 换行。如果你用 Windows 记事本保存，默认 CRLF 可能会让 NASM 在某些字符串场景下多出不可见字符。第三，全文使用英文标点，特别是逗号、冒号、引号。

汇编语法里，标签后面必须有冒号，比如_start:。漏了冒号时，NASM 不会直接报"你漏了冒号"，而是给一个看似奇怪的警告：label alone on a line without colon might be an instruction。意思是说，一个单独出现的标识符，后面没跟冒号，NASM 会把它当成指令助记符去解析，自然就乱套了。

此外，建议每一行只写一条指令，操作数之间用英文逗号并留一个空格。把声明区.data和代码区.text分开，是后面所有示例都会遵守的约定。

3. 手把手走一遍上机流程：从源码到调试器

3.1 一个最小的 Linux x86-64 汇编程序

下面是完整的 hello.asm。它在屏幕上输出一行Hello, assembly!，然后正常退出。你可以把这段代码视为后续所有上机实验的基础模板。

; hello.asm - 最小Linux x86-64汇编程序 section .data msg db 'Hello, assembly!', 10 len equ $ - msg section .text global _start _start: mov rax, 1 ; sys_write mov rdi, 1 ; fd = stdout mov rsi, msg ; buffer address mov rdx, len ; length syscall mov rax, 60 ; sys_exit xor rdi, rdi ; status = 0 syscall

在.data段里，msg db 'Hello, assembly!', 10定义了一串字节：先是 H、e、l、l、o 这样的 ASCII 字符，最后是数字 10。10 在 ASCII 里是换行符，不是字母。紧接着的len equ $ - msg用当前位置$减去 msg 的起始地址，得到字符串的字节长度。这种写法很常见，你不需要自己数有多少字符，汇编器会替你算。

.text段里的global _start是导出符号。_start是程序入口。为什么叫_start？因为后面链接器默认寻找这个符号作为入口点。你可以通过-e参数改名字，但课程里建议始终用_start，和教材、工具链的习惯保持一致。

指令部分四行 mov 分别设置系统调用号和三个参数，然后syscall触发内核调用。整体含义是：调用 write 系统调用，往标准输出（文件描述符 1）写入一段地址从 msg 开始、长度为 len 的内容。

3.2 为什么用 syscall 而不是 DOS 中断

写 Linux 系统调用时，遵循一套固定规则：rax 放系统调用号，rdi、rsi、rdx、r10、r8、r9 依次放前六个参数。我们的 write 需要三个参数：文件描述符、缓冲区地址、字节数。所以 rax=1，rdi=1，rsi=msg，rdx=len。最后用 exit 系统调用让程序结束，rax=60，rdi=0 表示退出状态为 0。如果不调用 exit，程序会继续执行后续内存中的随机内容，导致段错误。

这里涉及一个很多新手困惑的点：为什么不是 int 21h？因为那是 DOS 时代的接口。Linux 内核向用户态提供的接口是 syscall 指令，配合寄存器传参。两者思路相同：都是把"请操作系统帮忙"的请求号和参数放到约定位置，然后触发切换。我们在系统结构课上理解"用户态与内核态"，syscall 就是最直接的例子。

3.3 汇编、链接、运行三条命令

文件写好后，进入终端：

nasm -f elf64 -g -F dwarf hello.asm -o hello.o ld -o hello hello.o ./hello

第一行命令中，-f elf64表示生成 64 位 ELF 目标文件。ELF 是 Linux 可执行文件的标准格式，.o和可执行文件都用它。-g表示生成调试信息，-F dwarf指定调试信息格式为 DWARF。没有调试信息也能汇编链接，但 GDB 里看不到变量名和源码行，所以课程中建议默认带上。

第二行 ld 只需给出输出文件名和输入目标文件。它默认去找_start作为入口符号，并把代码段、数据段安排到虚拟地址空间。如果你之前忘了global _start，这一步就会报错。

运行./hello会看到输出。再用echo $?查看退出码，应该为 0。这一步虽然简单，但建立了一个闭环：你写了一个程序，通过汇编和链接变成了可执行文件，执行后向内核请求了输出，并以指定状态退出。

3.4 利用 file、readelf、objdump 检查各阶段产物

上机过程不只是敲三条命令。建议每产生一个文件都检查一下类型：

file hello.asm hello.o hello readelf -h hello | grep Entry objdump -d hello

file 会告诉你 hello.o 是ELF 64-bit LSB relocatable，hello 是ELF 64-bit LSB executable；readelf 能看到程序入口地址；objdump 能反汇编出来，验证你写的 mov 是否和机器码一一对应。这一组工具能让你把"黑盒"拆开看，为后续实验打基础。

4. 上机最常见的报错与一次段错误的完整排查链路

4.1 汇编阶段的常见语法报错

看到错误先别慌。下面是几类我见过无数次的 NASM 报错，第一次上机前扫一眼，能省掉很多时间。

定位语法错误最直接的办法，就是看 NASM 输出里的文件名和行号。先改那一行；如果改了还报错，可能是它上面某条指令没有闭合，例如字符串引号没写全，导致汇编器把后续内容都当成字符串，直到遇到下一个引号。这类错误报出来的行号可能远在错误点之后，所以不要机械地只看行号。

4.2 链接阶段的_start经典问题

链接阶段最常见的报错，都和_start相关。如果你在 .asm 里写了_start却没有global _start，链接器会警告：cannot find entry symbol _start; defaulting to ...。在某些情况下，如果多个目标文件都没有入口，会变成undefined reference to '_start'。

我把这个坑单独拿出来，是因为它和"符号可见性"有关。global 关键字告诉汇编器：这个符号要写进目标文件的符号表，并且允许外部模块引用。没有 global，标签只在当前文件内部有效，链接器从目标文件找入口符号时自然找不到。另一个易错点：如果你的项目有多个 .asm 文件，_start只能出现一次，因为链接器不能同时跳到两个入口。

4.3 运行时段错误：一次完整排查

运行时最常见的错误是段错误。我的建议是：不要靠猜，用 GDB 定位到出错的那条指令。比如下面这段故意写错的程序：

; 有问题的写法 section .data msg db 'Hello', 10 section .text global _start _start: mov rax, 1 mov rdi, 1 mov rsi, 0 ; 故意把缓冲区地址设为 0 mov rdx, 5 syscall

运行./hello会直接 Segmentation fault。原因很清楚：让内核从地址 0 读取 5 字节，内核检查到非法地址后杀掉了进程。但如果你的程序更复杂，可能很难一眼看出问题。

排查步骤是这样的。先用gdb ./hello启动，然后break _start，再run到入口。执行info registers看看 rsi 当前值。接着用stepi一条一条走，在 syscall 之前停住，检查 rsi、rdx。也可以x/5i $rip看即将执行的指令，或x/5bx $rsi看指针指向的内存是否可读。一旦发现 rsi=0，问题就出来了。

这个思路对一切段错误都有效：先找是哪条指令触发了非法访问，再看访问了哪个地址，最后看这个地址为什么非法。常见原因无非几种：寄存器没赋值、字符串长度算错、缓冲区地址被覆盖、栈指针越界。

这里还要强调一个容易误导人的点：段错误的崩溃位置不一定是真正的错误源头。比如你之前把 rsi 改成 0，然后中间又执行了几条不相关的指令，最后在 syscall 处才崩溃。GDB 单步可以让你看到崩溃前的完整指令序列，再往前翻几行，错误源头就出来了。

5. 用 GDB 看清每条指令：寄存器、内存和栈的观察方法

5.1 在入口处中断，查看寄存器初值

回到正确程序上，用 GDB 把运行过程完整看一遍。启动后先break _start，再run。程序会停在入口处，还没有执行任何指令。这时候info registers看到的，就是操作系统加载程序后、第一条指令执行前的现场。

常用寄存器的用途可以整理成一张表：

RSP 指向栈顶，栈顶存放 argc，也就是命令行参数的个数。对于./hello，argc=1。用x/8gx $rsp能看到这个数字和后面的 argv 指针数组，这是程序与操作系统交互的公共区域。很多 C 语言书里说main(int argc, char **argv)，其实在入口之前，这些参数已经被内核按约定放在栈上了。

RAX 等通用寄存器在入口处一般没有保证值，你不要依赖它。程序第一条指令会重新给它们赋值。

5.2 单步执行与动态观察寄存器

GDB 里单步执行汇编指令用stepi，简写si。每次执行 si，RIP 就推进一条指令。可以用info registers持续观察 RAX、RDI、RSI、RDX，也可以提前设置display/x $rax，让它在每次停下来后自动显示，这样不用反复敲命令。

更直观的方式是切到 TUI 模式。layout asm会显示汇编指令窗口，当前指令被高亮；layout regs会显示寄存器窗口，每次执行完自动刷新。再执行一次set disassembly-flavor intel，反汇编风格就和 NASM 一致，读起来不别扭。

走几步到 syscall 之前，你会发现寄存器值变成了 1、1、msg 地址、5。这里每一步 mov 都在为 syscall 准备参数。你完全可以当场改一个值，比如set $rdx=2，再continue，程序输出会变短。这种直接改寄存器的手法，比反复改源码再重新汇编高效很多。

5.3 查看内存里的字符串和初始栈

汇编程序里没有高级语言那样的变量名可以直接 print，但可以按地址看内存。x/s msg能按字符串格式打印；x/16bx msg按字节打印十六进制和 ASCII，你会亲眼看到 Hello 末尾的换行符 0a。这个 0a 之所以存在，是因为你在 db 里写的数字 10。

栈的观察更有意思。入口处 RSP 是栈顶，x/10gx $rsp可以看到 8 字节一组的数据。第一组是 argc，第二组开始是 argv 指针数组。数组里的每个指针，指向一个字符串，也就是命令行参数。想看第一个参数的内容，可以执行x/s *(void**)($rsp+8)。这些细节，在系统结构课上讲"程序启动"时非常有用。

5.4 在 syscall 上设置断点

汇编程序没有函数名，怎么在 syscall 上断？两种简单办法。一是先disassemble _start得到每条指令的地址，再用break *0x...设地址断点。二是从入口用 si 步进，等看到 RIP 指向那条 syscall 时，输入break *$rip。第二种更动态，注意$rip是 GDB 变量，取的是当前指令地址。

如果想让程序连续执行到下一个断点，用continue。调试多个系统调用序列时，可以先在入口断一次，观察寄存器；再在第二个 syscall 处断，比较两处参数分布。这对理解"系统调用上下文"很有帮助。

6. 把上机练成"底层切片"：一些实用经验

6.1 问题定位顺序：先判断阶段，再看细节

分享一个我自己用过无数次的排查顺序：遇到问题，先问自己程序卡在哪个阶段。汇编报错，看源码语法；链接报错，看符号和入口；运行崩溃，用 GDB 找指令。这个顺序看起来简单，但很多人一上来就盯着代码改，忽略了阶段判断，结果把语法错当成逻辑错，越改越乱。

每个阶段都有固定的验收命令：汇编通过会生成 .o，链接通过会生成可执行文件，运行通过会看到输出。你在心里把已完成步骤划掉，剩下没完成的自然就是问题所在。这个习惯，比记住任何一条具体指令都值钱。

6.2 把 hello.asm 当成模板，配一个 Makefile

我建议把可用的 hello.asm 存成一个模板。后续实验要输出数字、读文件、调用 C 库，都可以在这个骨架上改。模板固定包含.data、.text、global _start、以及写入和退出的系统调用段。这样每次面对新实验，只需要关注新增逻辑，而不是重复纠结环境问题。

Makefile 不是汇编课必学内容，但写一个十几行的文件能让你后续上机舒服很多。下面这个版本够用：

hello: hello.o ld -o $@ $^ hello.o: hello.asm nasm -f elf64 -g -F dwarf hello.asm -o $@ clean: rm -f hello hello.o

$@表示目标文件名，$^表示所有依赖文件。注意 Makefile 的缩进必须是 Tab，不能是空格，否则会报错。

6.3 程序跑通之后，可以接着做的几件事

程序跑通只是开始。想做点更有价值的练习，按这个顺序来：第一，给程序加一个读键盘输入的片段，观察 read 系统调用的参数；第二，用 GDB 把寄存器改乱，观察程序行为如何变化，这比反复改源码更接近底层调试；第三，用 objdump 把自己的可执行文件反汇编，对比你写的汇编和机器码之间的关系；第四，如果课程进入函数调用章节，在 call 和 ret 之间设断点，看返回地址如何被压在栈顶。

把这个最小的上机示例延伸出去，你会慢慢发现：汇编语言实验的真正价值，不是记住指令，而是让你对程序的每一步行为都有确定的、可观察的解释。这种解释能力，正是后面学系统结构时最需要的东西。

我当年学汇编时，最吃亏的一件事就是急着写复杂功能，结果一遇到问题就在一堆代码里找，效率极低。后来我给自己定了一个规则：每次上机，先跑通一个空的最小程序，再往里面加功能。这个方法听起来很笨，却是我能想到的最快路径。如果你想在上机环节少走弯路，不妨也试试：先看懂四个阶段，再动手写第一条指令。