简介：这是一份围绕哈工大计算机系统课程 CSAPP 大作业整理的报告文档，以经典 hello 程序从源代码到可执行文件、再到进程运行的完整生命周期为主线，适合正在完成预处理、编译、汇编、链接及系统级实验的学生对照学习。压缩包内仅有 1 个 doc 文件，大小约 6.44MB，内容以课程报告正文、目录和实验解析为主，便于直接查阅与整理。文档结合 Ubuntu 环境下的具体命令，逐章讨论 hello 的预处理结果、编译与汇编产物、链接过程，并延伸到进程管理、信号与异常、内存管理、I/O 管理等知识点，对中间文件和底层机制有较细说明。目前已有 358 人学习或下载，可作为梳理 CSAPP 知识框架、复盘大作业写作结构与理解程序运行链路的参考资料。

1. 一个 hello 能拆两万字：这份大作业讲的是从源码到进程的完整链路

很多人第一次看到「程序人生：Hello 的 P2P」这个题目都会觉得夸张——打印一行字而已，凭什么写两万字？真按从程序到进程这条路把 hello 走一遍，你会发现每一步都能往下挖：预处理之后三十行的源文件涨到三千多行，readelf -r里躺着几条等着被改写的重定位记录，strace ./hello能抓到 fork、execve、缺页和 write 的完整轨迹。这份计算机系统课程的大作业就是沿这条链写下来的，从预处理一路讲到 I/O 管理，每一章都配了命令、中间文件和寄存器级的逐行解析。正在赶系统级大作业、需要一份可对照写法模板的人，和想补一遍底层链路又不想重啃教材的开发者，都能直接从里面的命令和中间文件开始抄。

2. 环境与产物地图：五条命令生成的中间文件各管什么

动手之前得先把一件事想清楚：这套流程里真正有信息量的不是最后那个可执行文件，而是中间那一串.i、.s、.o。中间文件留不留得住，直接决定后面能不能写——很多人写完预处理那章就卡住，原因是gcc -E的输出随手扔进/tmp，第二天想看宏展开只能重跑一遍，结果环境变了，行号对不上，前面的截图全废。

2.1 工具链自检：版本和架构决定了你看到的汇编长什么样

在 64 位 Ubuntu 上做这套东西，第一步不是写代码，是把工具链版本固定下来并写进报告。x86-64 的寄存器命名、函数调用约定、重定位类型都跟架构绑死，而readelf、objdump的输出格式随 binutils 版本有细微差异，报告里贴的截图和命令必须出自同一次环境，否则评审一对照就露馅。

# 环境自检：这四条输出建议直接贴在报告第 1 章的「环境与工具」里 gcc --version | head -n 1 # GCC 主版本，后面的汇编风格跟它强相关 ld --version | head -n 1 # 链接器版本，动态链接器路径和它绑定 uname -m # 必须是 x86_64，i686 上做出来的东西完全不是一回事 readelf --version | head -n 1 # binutils 版本，节头表字段顺序会随版本微调

这几条命令本身没什么门槛，关键在「固定」两个字。gcc --version之所以只取第一行，是因为后面几行是版权声明，贴进报告纯占地方；uname -m拿的是内核架构字符串而不是uname -r的内核版本号，前者决定指令集，后者跟你读汇编毫无关系。工作目录我一般这么分：

mkdir -p ~/hello-life/{src,build,evidence} cp hello.c ~/hello-life/src/ cd ~/hello-life/build

src放原始源码，build放所有中间产物，evidence专门存命令输出和截图。分开的理由很实在：写到第 5 章回头看hello.i时，你要的是「命令行可复现」，而不是在满屏文件的目录里翻。

2.2 五阶段产物对照表：每个文件由哪条命令生成、该看什么

下面这张表是整份作业的骨架。写报告时按阶段推进，每推进一格就落一个文件、留一份输出，链条断在哪一格一目了然。

表里最容易翻车的是「编译」那行。默认gcc -S会带上不必要的伪指令和栈保护代码，读起来很吵。我一般显式关掉：

gcc -S -O0 -fno-asynchronous-unwind-tables -fno-stack-protector hello.i -o hello.s

-O0是必须的，-O1起编译器就开始把变量往寄存器里塞、把循环重排，你按源码逐行对寄存器会翻车；-fno-asynchronous-unwind-tables去掉.cfi_*那堆调用帧信息，让汇编干净到能一段段讲；-fno-stack-protector关掉栈保护桩，否则 main 的开头会莫名其妙多出一段%fs:40相关的代码。这三个参数不是必须，但报告要让别人看懂，值得加。

源码本身长这样，后面所有分析都围着它转：

#include <stdio.h> #include <unistd.h> #include <stdlib.h> int main(int argc, char *argv[]) { int i; int sleepsecs = 2.5; /* 隐式截断成 int，实参是 2 */ if (argc != 3) { printf("Usage: Hello 学号 姓名!\n"); exit(1); } for (i = 0; i < 10; i++) { printf("Hello %s %s\n", argv[1], argv[2]); sleep(sleepsecs); } return 0; }

注意int sleepsecs = 2.5;这行，它是整份作业里唯一一处隐式类型转换的素材，浮点常量在编译期被截断成 2 存进.rodata段。写报告时这行别改，改了后面「数据」小节就没东西讲了。

2.3 报告骨架：八章怎么挂到一条主线上

原文档的目录结构是「概述 → 预处理 → 编译 → 汇编 → 链接 → 进程管理 → 存储管理 → I/O 管理」，八大章。这个划分本身没问题，问题在于很多人写完发现像八篇互不相干的笔记。真正的黏合剂是两条线：P2P（Program to Process，从程序到进程）和 020（Zero to Zero，从系统零状态到进程痕迹被回收）。

我的建议是每章开头用一句话把当前阶段挂回主线，比如汇编那章就说「这一步把汇编文本变成可重定位目标文件，它是进程虚拟地址空间里.text段的雏形」。八章写下来，读者看到的是一条连续的路，而不是八个孤立知识点。这个思路在后面二次开发时同样适用——脚本也是按这条线串的。

3. 预处理到链接拆解：hello.i 的三千行、hello.s 的寄存器与 hello.o 的重定位表

这一章是整份文档里最需要「逐行抠」的部分。四个阶段，每个阶段都要拿出可验证的证据：预处理看行号，编译看寄存器，汇编看表，链接看地址。缺一个，报告就从「分析」降级成「流程复述」。

3.1 预处理：hello.i 里多出来的三千行从哪来

gcc -E hello.c -o hello.i # 等价的另一种写法，老系统上 cpp 是独立可执行文件 cpp hello.c > hello.i

-E的意思是「只做预处理就停下」，-o指定输出。两条命令结果等价，区别在于gcc -E会带上编译器默认的搜索路径，cpp直接调预处理器，两者在-I路径处理上偶有差异。作业里两种都写上，说明你验证过。

跑完之后第一件事是看行号：

wc -l hello.i # 3065 行 grep -n "int main" hello.i # 原始代码落在 3046 行之后

3065 和 3046 这两个数字非常关键，它直接回答了「预处理做了什么」这个问题的一半：三千多行里有三千行不是你的代码。另半步靠翻内容：

sed -n '1,40p' hello.i # 开头是头文件搜索路径的展开记录 sed -n '3046,3065p' hello.i # 末尾才是你写的 20 行

开头那一段是#include <stdio.h>被展开的结果——预处理器把/usr/include/stdio.h以及它内部再#include的其他头文件整棵复制进来，所以行数暴涨。中间那些#define定义的行号信息，是给编译器报错用的，报错时能指回原始.c文件而不是.i。至于宏替换，printf里任何用到NULL、EOF的地方都会变成字面值，条件编译段则按当前平台把不满足条件的分支整段删掉。这四件事——头文件展开、宏替换、去注释、条件编译——就是预处理能做的全部，报告里一句一句对上文件内容讲，比抄概念有用得多。

3.2 编译：hello.s 的数据段、跳转与寄存器分配

gcc -S -O0 -fno-asynchronous-unwind-tables -fno-stack-protector hello.i -o hello.s

从.i到.s，编译器要做词法、语法、语义分析和代码生成。落到 hello 这个例子上，能讲清楚的只有三类东西：数据往哪个段放、控制流用哪条跳转、函数调用的参数怎么传。

.section .rodata .LC0: .string "Usage: Hello 学号 姓名!\n" # 无占位符，后面会被优化成 puts .LC1: .string "Hello %s %s\n" # 有占位符，走 printf .data .align 4 .type sleepsecs, @object .size sleepsecs, 4 sleepsecs: .long 2 # 2.5 编译期截断成 2

这段是全篇最有讲头的地方。.rodata放只读常量，.data放已初始化的全局变量；.align 4是四字节对齐，让sleepsecs的地址能被 4 整除，CPU 取这个变量时一次访存就够。sleepsecs在源码里是int，但初值写的是2.5，编译器在编译期就把它截断成 2，你永远看不到运行期的浮点运算——这是隐式类型转换最直观的证据。另外.string里那个中文字符串是 UTF-8 编码，一个汉字占 3 字节，报告里可以顺带点一句字符串长度怎么算。

再看 main 的开头：

main: pushq %rbp movq %rsp, %rbp # 建立当前栈帧 subq $32, %rsp # 开辟 32 字节局部空间 movl %edi, -20(%rbp) # argc 从寄存器落到栈 movq %rsi, -32(%rbp) # argv 首地址落到栈 cmpl $3, -20(%rbp) # argc 与 3 比较，设置条件码 je .L2 # ZF=1 说明 argc==3，跳过 usage 分支

%edi和%rsi是 x86-64 调用约定里第一、第二个整型参数的位置，上一个调用者（__libc_start_main）把参数放这儿，main 进来先把它们存栈，因为后面这几个寄存器还要被printf、sleep用掉，不存就丢了。-20(%rbp)和-32(%rbp)的偏移不是随便挑的：argv是指针，8 字节，必须 8 字节对齐，所以落在-32；argc是 4 字节int，落在-20刚好不冲突。循环里%rbp-4是i，i++就是一条addl $1, -4(%rbp)。

访问argv[1]时用的是movq -32(%rbp), %rax拿首地址，再addq $8, %rax偏移——指针算术在这里就是加 8 的字节偏移，数组连续存储这件事在汇编层面看得一清二楚。控制转移那块，if (argc != 3)被编译成cmp加je，for循环被编译成cmp加jle，两条都依赖上一条cmp设置的条件码寄存器，这是「比较和跳转分离」的经典结构。

函数调用部分值得单独起一段。printf("Usage: ...")因为格式串里没有任何占位符，编译器把它替换成了puts@PLT，少一次格式解析；第二个printf("Hello %s %s\n", ...)有占位符，老老实实走printf@PLT。exit(1)把 1 放进%edi再call exit@PLT，sleep(sleepsecs)把sleepsecs的值放%edi再call sleep@PLT。所有这些@PLT后缀的意思是：目标函数在共享库里，现在还不知道地址，先留个桩，链接阶段再填。这就自然过渡到下一节。

3.3 汇编：readelf 读 hello.o 的节头表与重定位条目

gcc -c hello.s -o hello.o readelf -h hello.o > hello_elf.h.txt # ELF 头：类型是 REL，可重定位 readelf -S hello.o > hello_elf.S.txt # 节头表 readelf -r hello.o > hello_elf.r.txt # 重定位条目 readelf -s hello.o > hello_elf.s.txt # 符号表

-c表示编译到目标文件为止，不链接。readelf -h里最该看的是Type: REL (Relocatable file)，它明确告诉你这个文件还不能执行，里面的地址全是相对偏移，等着链接器来重定位。

readelf -S的输出是一张节头表，重点看这几节：.text存机器指令，.rodata存只读数据，.data存已初始化全局变量，.bss存未初始化全局变量（实际不占文件空间，只记大小），.symtab是符号表，.rela.text是代码段的重定位表。hello.o 里.bss大小是 0，因为源码里没有未初始化的全局变量，这一点可以顺手在报告里点一句，证明你真的看了。

重定位表才是这一节的重头戏：

readelf -r hello.o # 输出大致长这样（偏移和类型随版本略有差异） # Offset Info Type Sym. Value Sym. Name + Addend # 00000000001a 000500000004 R_X86_64_PLT32 00000000 puts - 4 # 000000000025 000600000004 R_X86_64_PLT32 00000000 printf - 4 # 000000000030 000700000004 R_X86_64_PLT32 00000000 exit - 4

每行的含义要能吃透：Offset是被改写位置在.text节里的偏移，Type是重定位方式，Sym. Name是引用的外部符号，Addend是加数。R_X86_64_PLT32的意思是「链接时把这里填成符号的 PLT 桩地址减去当前指令地址再减 4」，减 4 是因为 x86 的call指令相对偏移是从下一条指令开始算的。为什么全是指向puts、printf、exit、sleep、getchar这些外部函数？因为它们定义在libc.so里，汇编阶段根本不知道地址，只能留空。这就是「可重定位」三个字的实际含义，比背定义强多了。

3.4 链接：重定位落地、虚拟地址空间与动态链接

gcc hello.o -o hello # 想看非 PIE 的固定地址布局，加 -no-pie gcc hello.o -o hello -no-pie

不加-no-pie时，现代发行版默认生成位置无关可执行文件，代码段地址是随机基址加偏移，报告里讲「虚拟地址空间」会很别扭。加-no-pie之后代码段从0x400000附近开始，readelf -l hello里能看到一两个LOAD段，地址是固定值，讲起来顺畅得多。这也解释了为什么很多同类报告里地址都从0x4005xx起——不是巧合，是链接选项决定的。

链接器干两件事：符号解析和重定位。符号解析是把hello.o里那些「未定义」的puts、printf与libc.so里「已定义」的同名符号对上号；重定位是按.rela.text里的条目，把.text里预留的占位值改写成真实地址。

readelf -l hello # 段表：看 LOAD 段和入口地址 readelf -d hello # 动态段：看 NEEDED 依赖 ldd hello # 运行时依赖哪些共享库 objdump -d -r hello # 反汇编并标出重定位后的结果

readelf -l里Entry point address就是execve之后 CPU 开始取指的地址。段表里你会看到两个LOAD段，一个只读可执行（装.text、.rodata），一个可读写（装.data、.bss），这正是后面存储管理那章要讲的页权限的来源。readelf -d里的NEEDED项写着libc.so.6，说明这个程序是动态链接的；如果静态链接，ldd会直接告诉你「not a dynamic executable」。

objdump -d -r hello是最有说服力的一条命令，它把链接之后的机器码反汇编出来，原来call puts@PLT那些桩已经被填成了真实偏移：

00000000004005a0 <main>: 4005c6: e8 b5 fe ff ff callq 400480 <puts@plt> 4005d0: e8 9b fe ff ff callq 400470 <printf@plt>

这里的400480不是puts的真实地址，而是 PLT 表项的地址，第一次调用时 PLT 会跳去动态链接器解析真实地址并回填，后续调用直接命中。这条「延迟绑定」链路在报告里单独写一段，比单纯贴一张重定位表更能说明问题。写到这儿，从源码到可执行文件的整条链就闭环了，下一步该让它跑起来。

4. 运行期拆解：fork/execve 起进程、四级页表换地址、printf 落到 write

静态分析做完，程序还躺在磁盘上。真正的黑匣子在运行期：shell 怎么拉起一个进程，虚拟地址怎么变成物理地址，一行printf最后落到哪个系统调用。这三件事分别对应文档里的进程管理、存储管理和 I/O 管理三章，也是整份作业里最容易被写成概念堆砌的部分——因为看不见。好在 Linux 把大部分观测手段都摆出来了。

4.1 从 shell 到 execve：fork 与程序替换的完整链路

在终端敲./hello 学号 姓名，动手的是 shell。shell 本身是个循环：打印提示符、读一行、解析成命令和参数、然后创建子进程。

/* shell 内部逻辑的简化版，帮助理解 fork + execve 的分工 */ pid_t pid = fork(); /* 复制当前进程，父子各返回一次 */ if (pid == 0) { /* 子进程：把自己整个替换成 hello */ char *argv[] = {"./hello", "学号", "姓名", NULL}; execve("./hello", argv, environ); /* 成功则永不返回 */ _exit(127); /* 走到这说明 execve 失败 */ } else { int status; waitpid(pid, &status, 0); /* 父进程阻塞等待子进程结束并回收 */ }

fork返回两次是理解进程创建的关键：父进程拿到子进程 PID，子进程拿到 0。子进程接着调execve，这一步会删掉当前进程用户空间的全部区域结构，按 hello 的 ELF 段表重新映射代码段、数据段、bss、栈和堆，然后设置程序计数器指向入口地址——也就是上一节readelf -l看到的那个Entry point address。execve成功不返回，因为「当前程序」已经不存在了。

这一整套动作可以用strace直接看到：

strace -f -e trace=process,memory,write ./hello 学号 姓名

-f跟踪子进程，-e trace=只保留进程、内存和写三类调用，输出不至于刷屏。你会依次看到clone（fork在 Linux 上由clone实现）、execve、一连串mmap（映射 ELF 段和共享库），最后是write。这条轨迹贴进报告，比任何文字描述都硬。进程运行期间如果收到信号，比如 Ctrl+C 发来的SIGINT，shell 会把它转发给前台进程组，hello 没有注册处理函数，于是走默认动作终止——信号处理那段可以用kill -SIGINT <pid>手动验证一次。

4.2 逻辑地址到物理地址：段式、页式、TLB 与四级页表

地址变换这块，x86-64 上其实分两步：先段式，再页式。段式在 64 位下基本被架空了，除了%fs、%gs还用于线程本地存储，其余段的基址都是 0、界限拉满，所以逻辑地址等于线性地址。这一点报告里必须写清楚，很多人照搬 32 位教材讲一堆段选择子，结果和实际对不上。

真正干活的是页式。x86-64 用四级页表，48 位虚拟地址被切成 9+9+9+9+12 五段：前四段分别是 PGD、PUD、PMD、PTE 的索引，每级表 512 项、每项 8 字节，正好一页 4KB；最后 12 位是页内偏移，对应 4KB 页大小。

cat /proc/self/maps # 看当前进程的虚拟地址区域划分 cat /proc/<pid>/maps # hello 运行期间另开终端看它的映射

maps输出每一行是「起始地址-结束地址 权限 偏移 设备 inode 路径」，你能看到r-xp的代码段、rw-p的数据段、以及libc.so.6的若干映射。这些权限直接来自 ELF 的段表，也是 4.1 节execve做内存映射时的依据。想更进一步，可以读/proc/<pid>/pagemap拿到某个虚拟页对应的物理页框号，但需要 root 权限，且不同内核版本字段布局有变化，报告里作为拓展提一句就行，别陷进去。

TLB 是这层变换的缓存，缓存的是「虚拟页号到物理页框号」的映射项。四级页表意味着一次没命中就要访存四次，加上取指取数，开销非常难看，所以 TLB 命中率对性能影响极大。写报告时可以顺手做个对比实验：让 hello 顺序访问一个大数组，再让它按固定步长跳跃访问，用perf stat -e dTLB-loads,dTLB-load-misses量一下 miss 率，两者的数字差距足以支撑一整段分析。这种「自己动手量出来的数据」比复述概念值钱得多。

4.3 缺页异常与 I/O：printf 最终落到哪一次 write

程序刚execve完，代码段和数据段只是「映射好了」，物理页还没真正分配。第一次取指碰到代码页，MMU 查页表发现有效位是 0，触发缺页异常，内核的缺页处理程序介入：判断这个地址是否落在合法区域、权限对不对，然后分配一个物理页框，把磁盘上的对应内容读进来，更新页表，返回用户态重新执行那条指令。数据段的写操作同理，只不过写时复制的情况下可能还要先拷贝一份。

printf这条路径值得顺着往下捋。C 库的printf不是系统调用，它先把格式化结果写进FILE结构里的用户态缓冲区，等缓冲区满、遇到换行且是行缓冲、或者程序调用fflush/exit时才真正下发。真正落到内核的是write：

strace -e trace=openat,mmap,read,write ./hello 学号 姓名 # 关键几行大致是 # mmap(... libc.so.6 ...) = 0x7f... # write(1, "Hello 学号 姓名\n", 20) = 20 # read(0, ...) # getchar 对应 read

write的第一个参数 1 是标准输出的文件描述符，第二个是缓冲区地址，第三个是字节数。返回值 20 表示成功写入了 20 字节。注意Hello 学号 姓名\n里中文字符是 UTF-8 多字节，字节数不是字符数，这一点在报告里很容易算错，值得单独标注。

getchar反过来走read(0, buf, n)，从标准输入读。Linux 下一切皆文件，终端、磁盘文件、管道共用同一套read/write接口，区别在于内核里挂的是哪个驱动。这段可以接到文档里 I/O 管理那章的「UNIX I/O 接口及其函数」——open、close、read、write、lseek、stat六个函数撑起了整个抽象，其余都是在这之上包的。写到这里，020 的起点和终点都对上了：进程从零创建，最后被 shell 用waitpid回收，内核把它占用的页框、文件描述符、页表项全部清掉。

5. 避坑与排查：四条让报告返工的血泪记录

这套流程的命令不难，难在证据链要严丝合缝。下面四条是我拆这类项目时真踩过或者见别人踩过的，每条都足以让已经写好的章节整段重来，提前知道能省不少时间。

5.1 工具链版本不一致，汇编风格对不上

现象：第 3 章贴的hello.s里是pushq %rbp，第 5 章链接后反汇编出来变成push %rbp，同一个人写的报告里指令后缀前后矛盾；或者重定位类型在一台机器上是R_X86_64_PLT32，换台机器变成R_X86_64_PC32。

原因：objdump在 AT&T 语法下默认省略操作数宽度后缀，而gcc -S生成的汇编显式带后缀；不同 binutils 版本对某些重定位类型的选择也有差异，编译器版本不同还会改变-fPIC的默认行为。

解决：在报告最前面固定一段「环境与工具」，把gcc --version、ld --version、readelf --version三行输出原样贴进去，并且在所有反汇编命令上加-M att或-M intel明确语法，全文统一一种。中途换环境的话，所有截图和输出必须重跑一遍，不能新旧混贴。这条看起来是小事，实际是最容易被审出问题的地方。

5.2 readelf 输出看不懂，重定位条目与源码对不上

现象：readelf -r hello.o输出的Offset列是00000000001a这种十六进制，翻遍hello.s也找不到对应的行，不知道该拿它跟哪条指令关联。

原因：Offset是相对于所在节起始地址的偏移，不是文件绝对偏移，也不是行号。要定位到具体指令，得先拿到.text节在文件里的偏移，再算绝对位置，或者更省事——直接反汇编。

解决：用objdump -d -r hello.o，它把反汇编和重定位条目交织输出，每条call后面紧跟一行R_X86_64_PLT32 puts-0x4，一眼就能对上。想验证Offset的话，readelf -S hello.o里找到.text节的Address和Offset，两者在可重定位文件里通常相同，加上Offset就是文件位置。这个换算关系写进报告，比单纯贴输出强。

5.3 截图与命令不匹配，报告里的证据链断了

现象：正文里写的命令是gcc -E hello.c -o hello.i，配图却是cpp hello.c > hello.i的输出；或者分析里说「程序扩展到 3065 行」，实际wc -l打出来是另一个数字。

原因：写到后面回头补截图，环境已经变了，或者手动改过源码却没重跑全流程。这类错误自己看不出来，评审一对照就发现前后矛盾。

解决：从源头杜绝——所有中间文件由一条脚本一次性生成，脚本内容和报告里的命令一字不差，输出统一存到evidence/目录并带序号。写报告时只从evidence/里取图，不临时跑命令。第 6 章会给出这条脚本的具体写法。

5.4 观测手段侵入性太强，把进程行为改变了

现象：想观察 hello 的write调用，加了strace之后发现输出时序变了，sleep的间隔明显不准；或者用gdb单步跟execve，程序行为跟直接运行完全不同。

原因：strace靠ptrace系统调用拦截每一次陷入内核的操作，每次拦截都有两次上下文切换开销，对 I/O 密集或时序敏感的程序影响很大；gdb的断点、单步同样走ptrace，还会改变信号投递时机。

解决：区分「观察静态结构」和「观察运行时序」。前者用readelf、objdump，对运行零影响；后者用strace -c先看系统调用统计而不是逐条打印，或者用perf采样，侵入性小得多。真要逐条看，就在报告里明确标注「以下时序数据在strace下采集，仅用于观察调用顺序，不代表程序真实耗时」。这句话加上去，专业性立刻不一样。

6. 二次开发：把手工命令串成一条可复现的流水线

这套东西真正的复用价值不在报告本身，而在那串命令。手工敲一遍是学习，敲十遍就是浪费。我后来把整条链写成一个脚本，跑一次就把所有中间文件和证据输出落盘，改源码后重跑，diff一下就知道哪一阶段的输出变了。

#!/usr/bin/env bash # build_chain.sh：从 hello.c 一路走到可执行文件，每步留证 set -euo pipefail SRC=${1:-hello.c} OUT=${2:-evidence} mkdir -p "$OUT" # 每步都记录命令本身，保证报告里的命令和实际执行的一致 run() { echo "+ $*" | tee -a "$OUT/commands.log" "$@" 2>&1 | tee -a "$OUT/commands.log" } gcc -E "$SRC" -o hello.i gcc -S -O0 -fno-asynchronous-unwind-tables -fno-stack-protector hello.i -o hello.s gcc -c hello.s -o hello.o gcc hello.o -o hello -no-pie readelf -h hello.o > "$OUT/01_elf_header.txt" readelf -S hello.o > "$OUT/02_section_headers.txt" readelf -r hello.o > "$OUT/03_relocations.txt" readelf -l hello > "$OUT/04_program_headers.txt" objdump -d -r hello.o > "$OUT/05_disasm_reloc.txt" strace -e trace=process,write ./hello A B > "$OUT/06_strace.txt" 2>&1 wc -l hello.i hello.s > "$OUT/07_linecount.txt"

set -euo pipefail三件套保证任何一步失败立刻停，不会带着残缺产物往下跑；run函数把命令本身和输出写进同一份日志，事后回溯时不会出现「这条输出是哪条命令产生的」这种问题；最后把每类输出按序号命名，报告里引用时直接写文件名。这套东西跑通之后，二次开发的门槛就低了——想加一节分析 Cache 命中率，就在末尾追加一条perf stat；想对比-O2和-O0的汇编差异，改一行参数重跑，再diff hello.s就行。

这套脚本习惯是从一次惨痛返工里留下来的：当时改了个源码细节忘了重跑预处理，报告里贴的行号全是旧的，对着hello.i找了半天才发现是过期文件。从那以后我每次动源码，都强制走一遍完整脚本，让所有中间文件同源同版本。希望这些能帮到你，少绕几步。

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