简介：面向计算机系统（CSAPP）课程学习者的大作业范例文档，以「程序人生——Hello 的 P2P」为题，完整记录 hello 程序从源码到可执行文件、再在 Linux 上运行的整个生命周期。作者按章节梳理了预处理、编译、汇编、链接四个阶段在 Ubuntu 下的具体命令与中间结果解析，并延伸到进程管理、信号与异常、内存管理与 I/O 管理等操作系统层面的知识点，配有中间文件内容对照与可重定位目标 ELF 等细节说明。压缩包内共 1 个 doc 文件，约 6.44MB，为排版完整的课程报告，含摘要、目录与分章小结，可直接作为报告撰写结构与技术表述的参考。目前已有 358 人学习下载，适合正在准备 CSAPP 大作业、需要对照实验步骤与报告写法的高校学生使用。

1. 一个 hello 的 0 到 0：为什么值得把整条链路拆开看

敲下./hello到屏幕上出现两行字，中间隔了不到三毫秒。可就在这三毫秒里，有四个工具链程序先后改写过同一个文件，内核为它建了进程、重建了整张地址空间表，CPU 为它查了四级页表和三级缓存。一份把 hello 的“程序人生”从头跟到尾的课程报告，把这条链拆成两段来看：P2P（Program to Process）解释一个躺在磁盘上的静态文件怎么变成活着的进程，020（Zero to Zero）解释进程退出后内核怎么把痕迹抹干净。这套 CSAPP 式的追踪之所以值得细读，不是因为要背下 gcc 的四个参数，而是它把“源码→可执行→运行→回收”整条黑匣子打开了一次。看懂一次，以后遇到“符号未定义”“段错误”“改了头文件不生效”这些玄学，就知道该去链路的哪一环翻账本。

2. 预处理与编译：3065 行的 .i 是怎么膨胀出来的

2.1 预处理器只做四件事，却足以让代码膨胀七十倍

报告里有个数字很扎眼：一个几十行的 hello.c，预处理之后变成 3065 行，而真正手写的那部分源码被挤到了第 3046 行及之后。前面三千多行不是凭空生成的，是三个头文件递归展开的结果。预处理阶段做的事归结起来只有四件：把头文件内容原样复制进来、把宏替换成实际值、按#if系列指令裁剪代码、去掉注释。注意顺序，宏替换发生在头文件展开之后，所以头文件里定义的宏在源文件里也能用。

# -E 表示只做预处理，停在 .i 阶段，不往下编译 gcc -E hello.c -o hello.i # 等价写法，直接调用预处理器 cpp；区别是 cpp 不会带上 gcc 那套内建宏 cpp hello.c > hello.i # 看膨胀后的规模，以及原始代码落在第几行 wc -l hello.i grep -n "int main" hello.i

-E是关键参数，它让 gcc 在预处理结束后立刻收手；-o指定输出文件，省掉就打到标准输出。gcc -E和直接调cpp在大多数场景下结果一致，差别在于 gcc 会预定义__GNUC__、__x86_64__这类内建宏，而裸调 cpp 不一定带。这个差异在跨平台条件编译里会翻车，属于典型的血泪经验。

为什么展开后要保留# 1 "hello.c"这样的行控制指令？因为编译器报错和调试器单步都要靠它把 .i 里的行号映射回原始 .c 文件。少了这层映射，gcc 报的错会指向一个你从没写过的行号。宏替换则是纯文本层面的字符串替换，不做类型检查也不做括号补全，#define SQ(x) x*x传进1+2会得到1+2*1+2，这类问题在预处理阶段就已经定型，编译器后面根本无从纠正。

2.2 编译的五个阶段里，真正决定代码质量的是后两个

预处理之后进入编译，也就是从 .i 到 .s 的过程。教科书的划分是词法分析、语法分析、语义检查与中间代码生成、代码优化、目标代码生成。前三个阶段负责“发现你写错了”，后两个阶段负责“让正确的代码跑得快”。词法分析把字符流切成 token，语法分析把 token 序列组织成抽象语法树，语义检查核对类型是否自洽、变量是否声明，这三步走完才会生成中间表示（GCC 里叫 GIMPLE，再往下是 RTL）。

# 停在编译阶段，输出 AT&T 语法的汇编文本 gcc -S hello.i -o hello.s # 打开 O2 再生成一份，对比优化前后的差异 gcc -S -O2 hello.i -o hello_O2.s diff hello.s hello_O2.s | head -40

-S是停在汇编阶段的开关。这里有个容易忽视的选择：课程实验一般要求用-O0，理由是每条 C 语句和汇编指令大致能一一对应，方便对照分析；一旦开-O2，循环可能被展开、叶子函数的栈帧可能被省略（直接用 red zone 那 128 字节）、常量可能被折叠成立即数，语义等价但形态完全变了，再去逐行对照就失真。这就是一个很实在的设计取舍：可分析性和运行效率，在编译选项这一层就是对立的两端。

另一个取舍是为什么输出 .s 这种文本而不是直接给二进制。汇编这一层是人和机器之间的可读契约，保留文本形式，反汇编、调试、换目标文件格式时都有据可查，汇编器也能被不同语言前端复用。

2.3 变量落在哪个段，编译器在生成汇编时就定了

看 hello.s 最有价值的不是读指令，而是看数据被放到了哪里。字符串字面量"Hello %s %s\n"放在只读数据段，因为它运行期不该被改写；int sleepsecs = 2.5;这种带初值的全局变量通常落在 .data，而浮点常量赋给 int 是截断，且这个转换在编译期就完成了，所以汇编里看到的是立即数 2 而不是 2.5，也不会在运行期留下任何浮点指令。

.section .rodata .LC0: .string "Usage: Hello ...!\n" # 字面量进只读段，运行期写它会 SIGSEGV .LC1: .string "Hello %s %s\n" .text .globl main main: pushq %rbp # 保存调用者的栈帧基址 movq %rsp, %rbp # 建立当前栈帧 subq $32, %rsp # 开辟 32 字节栈空间 movl %edi, -20(%rbp) # argc 从 %edi 落到栈上 movq %rsi, -32(%rbp) # argv 指针数组首地址落到栈上 cmpl $3, -20(%rbp) # if (argc != 3) je .L2 # 相等则跳过错误处理分支

这几行把 x86-64 的调用约定交代得很清楚：前六个整型参数依次用%rdi、%rsi、%rdx、%rcx、%r8、%r9传，返回值放%eax；%rbp标识当前栈帧起点，局部变量一律用“基址 + 负偏移”寻址，而不是绝对地址——这样同一份代码加载到任何虚拟地址都能跑。if被编译成cmpl加je：比较指令设置条件码，je读 ZF 标志位，相等就跳。for (i = 0; i < 10; i++)则通常被改写成和 9 比较再jle，少一次减法，这是编译器最基础的等价变形。

数组的处理更能看出机器层的味道。char *argv[]里每个元素是指针，8 字节，所以argv[i]就是首地址加8*i；报告里观察到argv[1]、argv[2]被依次搬进%rsi、%rdx作为 printf 的第二、三个参数，正是这个寻址规则在起作用。函数调用一侧，call会把下一条指令地址压栈再跳转，ret则是把返回地址弹回%rip；leave一条指令等价于mov %rbp,%rsp加pop %rbp，把栈恢复到调用前状态。这些看着琐碎的细节，构成了后面链接和进程切换的全部前提。

3. 汇编与链接：ELF 节区、重定位表与 PLT 的填坑顺序

3.1 汇编器只翻译不解决地址，.o 里的目标全是占位符

汇编器 as 把 .s 里的助记符逐条翻成机器码，再打包成 ELF 可重定位目标文件。这一步有个关键约束：此刻它还不可能知道printf最终在内存的哪个地址，甚至不知道自己会被加载到哪。所以 .o 里凡是涉及外部符号或跨节引用的位置，全都先填 0 或填一个占位偏移，同时在这些位置登记一条“重定位条目”，等链接器来补。

# 只汇编不链接，产出可重定位目标文件 gcc -c hello.s -o hello.o # 看 ELF 头，重点看 e_type 是不是 REL（可重定位） readelf -h hello.o # 看节区表：.text/.data/.bss/.rodata/.symtab/.rela.text 都在这里 readelf -S hello.o | head -30 # 只看重定位表，这是链接器最关心的部分 readelf -r hello.o

-c是“编译并汇编但不链接”的开关。ELF 头的e_type有三个常见取值：REL可重定位（.o 文件）、EXEC可执行（非 PIE）、DYN共享对象或 PIE 可执行。.symtab符号表是给链接器用的，不会被加载进内存；真正加载时用的是.dynsym，这是不少人第一次看 readelf 输出时容易搞混的地方。

3.2 重定位条目记录链接器要补的每一处地址

重定位条目的结构不长，但每个字段都有明确分工：r_offset是“要改的位置在节内的偏移”，r_info高 32 位是符号表索引、低 32 位是重定位类型，r_addend是加数。

Relocation section '.rela.text' contains 6 entries: Offset Info Type Sym. Value Sym. Name + Addend 00000000001a 000500000002 R_X86_64_PC32 0000000000000000 puts - 4 00000000001f 000600000002 R_X86_64_PC32 0000000000000000 exit - 4 000000000030 000900000002 R_X86_64_PC32 0000000000000000 sleep - 4

R_X86_64_PC32是最常见的一种，计算方式是S + A - P：S 是符号最终地址，A 是加数，P 是被修改位置自身的地址。算出来的结果是一个相对位移而非绝对地址，这正是位置无关代码能成立的根本原因——无论整个模块被加载到哪，相对距离不变。R_X86_64_32和R_X86_64_32S则是绝对寻址，多用在数据段指针上，代价是模块必须加载到固定地址（非 PIE）。看懂这张表，基本就看懂了链接器一半的工作。

3.3 动态链接：为什么汇编里的 printf 变成了 printf@plt

如果每个 hello 都把 libc 整个塞进去，一个打印两行字的程序轻松到几百 KB，而且每个进程在内存里各存一份。动态链接的思路是把共享库单独映射，可执行文件里只留符号引用和一小段跳板。这段跳板就是 PLT（过程链接表）。

# 默认就是动态链接，链接器会写入依赖信息 gcc hello.o -o hello # 看依赖了哪些共享对象 ldd hello # 看 PLT 桩的实际形态，每个外部函数一段 objdump -d -j .plt hello | head -30 # 看 .dynamic 段里记录的 NEEDED 条目 readelf -d hello | grep NEEDED

ldd其实不是一个真正的可执行程序，它是一个脚本，靠设置环境变量让动态链接器把依赖打出来，所以对不可信文件跑 ldd 有风险，这条属于排查时的注意点。PLT 配合 GOT（全局偏移表）工作：第一次调用printf@plt时，GOT 里存的是“解析器入口”，跳过去由动态链接器 ld.so 查找 printf 的真实地址并回填 GOT；第二次调用就直接跳到真地址了。这套机制叫延迟绑定。

延迟绑定的收益是启动快——没调用到的函数一概不解析；代价是 GOT 必须可写，于是留下了 GOT 覆写的攻击面。工程上的对冲手段是-z relro -z now：启动时把所有符号一次性解析完，然后把 GOT 段改成只读，牺牲启动时间换安全性，这也是现代发行版默认开启的加固项之一。同一个机制，两种配置，取舍点非常清晰。

3.4 可执行文件的虚拟地址空间，链接时就已经规划好了

链接器按链接脚本把各段摆到虚拟地址上，程序头表（program header）记录的就是“哪些段要加载、加载到哪、权限是什么”。

readelf -l hello | grep -A2 LOAD # LOAD 0x000000 ... R E 0x400000 ← 代码段，可读可执行 # LOAD 0x000e10 ... RW 0x600e10 ← 数据段，可读可写

注意memsz和filesz的差值：文件里没内容，内存里却要占，这块就是 .bss。它不占磁盘空间，加载时由内核映射到匿名零页，写的时候才真正分配物理页。这条伏笔到下一章讲缺页时会兑现。PIE 编译下基址不再是固定的 0x400000，而是加载时随机选一个，这就是地址空间随机化在可执行文件层面的落点。

4. 进程与存储：fork/execve 之后，地址空间被重写了三遍

4.1 fork 只复制页表，不复制物理页

shell 读入./hello之后的第一件事是fork()。父子进程的虚拟地址空间看起来一模一样，但内核实际做的是写时复制：把父进程的每个页表项清掉可写位，父子共享同一批物理页；谁先写，谁触发缺页，内核这时才真正复制那一页。

/* 内核侧行为的示意，不是 hello.c 的原始代码 */ pid_t pid = fork(); if (pid == 0) { /* 子进程紧接着 execve，几乎不碰内存，所以一页都不用复制 */ execve("./hello", argv, envp); _exit(127); /* 只有 execve 失败才会走到这里 */ } /* 父进程继续，等子进程结束 */ waitpid(pid, &status, 0);

fork()的返回值有三态：小于 0 表示失败，等于 0 表示当前在子进程里，大于 0 表示当前在父进程、拿到的是子进程 pid。为什么设计成写时复制而不是直接全量复制？因为绝大多数 fork 后面紧跟 execve，复制了也是白复制。早年不做 CoW 的系统在 fork 一个大进程时会慢到不可用，这是踩过坑之后改的设计。上面代码里execve后面的_exit(127)也是必要的：execve 成功时永不返回，能执行到下一行只可能是失败，此时必须主动退出，否则子进程会把父进程的代码再跑一遍。

4.2 execve 的四步：把旧地址空间拆了重建

execve 做的事情报告归纳为四步，展开看每一步都在动内核数据结构。

第一步，删除当前进程虚拟地址用户部分里已存在的区域结构。注意是删“区域结构”（VMA），不是立刻回收物理页——那些页由引用计数决定何时真正释放。

第二步，为新程序的代码、数据、bss 和栈创建新的 VMA，全部私有、写时复制。.text 和 .data 映射到可执行文件对应的段；.bss、栈、堆是“请求二进制零”的，映射到匿名文件，初始长度为零。

第三步，如果程序依赖共享库（比如 libc.so），把这些共享对象映射到用户地址空间的共享区域。这一步是按需的，只有真正引用到的库才会被映射进来。

第四步，设置程序计数器，指向代码区域入口。真实情况下这个入口是动态链接器的_start，由它完成重定位后再跳到main。这也解释了为什么在 gdb 里break main能生效，而break _start断到的是另一段完全不同的代码。

4.3 逻辑地址到物理地址：段式打底，页式干活

x86-64 下段式管理基本被架空了：CS、DS 这些段寄存器还在，选择子还在，但基址一律设成 0、限长设为全空间，走的是平坦模型。所以逻辑地址到线性地址这一步几乎是恒等映射。真正干活的是页式管理：48 位虚拟地址被切成 4 段 9 位索引加 12 位页内偏移，依次查 PGD、PUD、PMD、PTE 四级页表，最后拼出物理页框号。

每查一级都是一次内存访问，四级就是四次，太慢。所以有了 TLB：它缓存最近用过的页表项，典型的一级数据 TLB 只有几十项，但命中率通常很高，因为程序的访存有强局部性。TLB 命中的话，虚拟地址到物理地址的翻译在一个周期内完成，一次内存访问都不会多。

# 看当前进程的地址空间布局，各段的起止和权限一目了然 cat /proc/self/maps # 缺页统计：minflt 是软缺页，majflt 是硬缺页 awk '{print "minflt="$10, "majflt="$12}' /proc/self/stat

软缺页指的是页已经在物理内存里、只是当前进程还没建立映射（写时复制、匿名零页都属于这类），处理代价小；硬缺页要从磁盘或 page cache 之外读入，代价高一个数量级。第一次跑 hello 比第二次慢，多半就是文件页还没进 page cache，走了硬缺页。

4.4 缺页故障：一次匿名页访问为什么能凭空得到零页

访问 .bss 里的全局变量，或者栈上未初始化的局部变量，对应的页表项是空的，CPU 触发缺页异常，内核的缺页处理程序开始判断：这个地址落不落在某个 VMA 里？落在哪个 VMA？

如果是匿名映射（.bss、栈、堆），内核分配一个全零的物理页建立映射，或者更省事地先映射到全局共享的零页并标只读，等真正写入时再复制一份——这又是一次写时复制。如果是文件映射，就从 page cache 里找，找不到再去磁盘读。如果地址压根不在任何 VMA 范围内，内核直接给进程发 SIGSEGV，进程当场死掉。所谓“段错误”，本质就是这个判断走到了第三个分支。

这也解释了报告里“BSS 区域是请求二进制零的，映射到匿名文件”这句话的机制来源：它不是真的有一个全零的文件躺在磁盘上，而是内核约定了一种匿名映射，读到的永远是零，写的时候才分配。

4.5 printf 到 write：格式化在用户态，落盘在内核态

printf 干两件事：按格式串把可变参数格式化成字节流，写进 FILE 结构体的缓冲区；缓冲区满了、遇到换行（终端行缓冲模式下）、或者显式 fflush 时，才真正调用 write 陷入内核。

/* glibc 中 printf 的简化路径示意 */ int printf(const char *fmt, ...) { /* 1. 解析格式串，按 %s/%d 依次取出可变参数 */ /* 2. 格式化结果写入 stdout 的缓冲区 */ /* 3. 缓冲区满 / 遇 \n（行缓冲）/ fflush 时调 write(1, buf, n) */ return written; }

getchar 是反过来的：read 一次读一大块进缓冲区，后续 getchar 逐字节从缓冲区取，取空了再触发下一次 read。所以while (getchar() != '\n')这样的循环不会产生十次系统调用，而是一次。理解这层缓冲，就能解释一个高频困惑：程序在终端里能实时打印，重定向到文件后却卡住不动——因为 stdout 连终端是行缓冲，重定向到文件变成全缓冲，4096 字节才刷一次。加个\n或者fflush(stdout)就好了。

5. 避坑排查：这些观察结果为什么和课本对不上

5.1 工具链上最容易翻车的四个点

坑一：改了头文件，重新编译却没生效。现象是明明改了自定义头文件里的宏，编译出来的程序行为还是旧的。原因是构建脚本只声明了 .c 对 .o 的依赖，没写 .h 的依赖，头文件时间戳变了不触发重编译。解决办法是用gcc -MMD -MP让编译器顺带生成依赖文件，把 .d 文件 include 进构建脚本，或者干脆每次验证前先清干净重来。

坑二：gcc -S hello.c和先-E再-S的结果对不上。现象是跳过预处理直接 -S，看到的汇编和分两步做的不一致。原因是 gcc 是一条龙驱动，-S 内部会自己先跑一遍预处理，这一步用的宏定义集合可能和手动那次不同（尤其是传了-D的时候）。想精确控制，就老老实实分两步：先-E确认宏展开结果，再对 .i 用-S。

坑三：readelf -r和objdump -r数出来的重定位条目不一样。现象是两个工具给出的条目数对不上。原因是 readelf 默认列出所有.rela.*节，objdump 默认只聚焦代码相关的部分，且对 RELA 加数的显示方式不同。排查时固定用readelf -r hello.o看全量，需要和反汇编对照时用objdump -dr hello.o一条命令把指令和重定位一起打出来。

坑四：反汇编 hello.o 看到的调用目标全是 0。现象是objdump -d hello.o里 call 的目标显示成下一行地址，偏移字段是 0。原因很简单：可重定位目标文件里这些位置还没被链接器填过，本来就是占位符。要看清真实调用关系，得先链接成可执行文件再反汇编，或者去.rela.text里对着 addend 手算。

5.2 运行时和内存观测上的三个陷阱

坑五：fork 之后 printf 的内容打了两遍。现象是父进程和子进程各输出一份相同内容。原因是 fork 复制了整个地址空间，包括 stdio 的缓冲区，父进程缓冲区里还没 flush 的内容被一起复制到子进程，两边各自 flush 一次就成了双份。解决办法是 fork 前fflush(stdout)，或者干脆用write这类无缓冲 IO。

坑六：程序没分配内存，缺页次数却一直涨。现象是一个纯计算的循环跑下来，minflt 数字稳步上升。原因是栈在增长，每深入一层调用都可能触碰一个新的栈页；另外写时复制在复制页时也会计一次软缺页。判断依据可以看/proc/pid/status里的 VmRSS 是否同步增长，或者用perf stat -e page-faults单独统计。

坑七：缓存命中率测出来每次都不一样。现象是同一段代码跑两遍，perf 报的 cache-misses 相差很大。原因是频率调节、中断干扰、页表预热都在影响结果。工程上的做法是跑够次数取中位数、用 taskset 绑核、把频率调节策略固定住，再对比不同版本的相对值而不是绝对值。

注意：观测本身会改变被观测对象。加 profiling、开 gdb、插 printf，任何一个动作都会扰动 cache 和分支预测器的状态，所以微基准的数字只能横向比，不能当成物理真值。

6. 设计取舍：分层带来的分工与代价

把这条链从头到尾走一遍，会发现它最核心的设计思想不是某个具体算法，而是分层。预处理、编译、汇编、链接、加载、执行，每一层只解决一类问题，层与层之间用明确定义的中间格式（.i、.s、.o、ELF 可执行）交接。代价很直接：中间表示多、工具多、出错点分散，一个“符号未定义”可能来自声明缺失、链接顺序不对、库路径没配、或者符号被static藏起来了，得逐层排查。收益同样直接：每一层都能被独立替换——换语言前端不影响汇编器，换目标架构不影响链接器，换共享库版本不用重编主程序。

我个人的教训是：一旦遇到链接期和运行期的怪问题，别急着猜，先把三件事跑一遍——readelf -r看重定位条目对不对，nm看符号是 T 还是 U，ldd看依赖有没有解析到预期的路径上。十次有八次，答案就在这三份输出里。从那以后我每次碰到底层相关的报错，都强制走一遍这套固定动作，比凭直觉改代码省的时间多得多。希望帮到你。

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