企业官网建设流程全解析

第一次看到大作业题目"程序人生 - Hello's P2P"的时候，说实话我是有点懵的。P2P？这不是点对点网络那套东西吗？显卡厂商聊的P2P互联、联机游戏里的P2P组网，咋成大作业题目了。直到翻开CSAPP教材，才发现这里的P2P是Program to Process——一个程序从源代码到可执行文件，再从静态文件变成动态进程的完整生命周期。这个题目起得确实精髓：用一个hello，把整本CSAPP串成了一条线。

这篇博客不打算给你贴一份现成的实验报告模板，而是想以我做完这套大作业之后的理解，把hello从.c文件到进程消亡的全过程讲清楚：每一站发生了什么、系统做了哪些关键动作、用什么命令能看到实际证据、作业里哪些地方最容易翻车。适合正在写CSAPP大作业的同学参考，也想给那些"虽然不交作业但想搞懂程序到底怎么跑起来"的开发者一点启发。

1. P2P不是点对点：这个作业到底想让你搞懂什么

1.1 CSAPP语境下的P2P，指的是Program to Process

CSAPP大作业里的P2P，全称是From Program to Process。它描述的是这样一个过程：你写了一个hello.c，它躺在磁盘上，是一个静态的、没有任何生命力的文本文件；经过预处理、编译、汇编、链接，它变成了一个可执行目标文件hello；然后当你在命令行敲下./hello并按下回车，操作系统把这个可执行文件加载进内存，创建一个进程来运行它——这时它才真正"活"过来。

所以P2P的完整路径是：

hello.c（源代码 Program） → hello.i（预处理后的源文件） → hello.s（汇编语言程序） → hello.o（可重定位目标文件） → hello（可执行目标文件 Program） → 进程（Process） → 进程终止、回收

前四步是把高级语言程序变成机器可执行的静态文件，后两步是把静态文件变成动态运行中的进程，最后是进程退出后由父进程回收。整个链条覆盖了CSAPP前面八章的核心内容：编译系统、链接、异常控制流、虚拟内存、系统调用、I/O、信号、进程控制。

1.2 大作业分数的关键：不是堆代码，而是建立"全链路"视角

我知道很多同学拿到这个作业的第一反应是上网搜一份报告模板，然后把自己的命令输出截图贴进去，就完事了。但如果你真想把分数拿稳，或者真的想从这个作业里学到点东西，思维得换一换：大多数作业报告的低分原因不是"没写够字数"，而是"原理和命令脱节"。

什么叫脱节？比如你贴了一张readelf -h hello.o的输出图，却没说ELF头里那串"magic number"是什么含义，没说e_type为什么是REL而不是EXEC。又比如你写了gcc -S hello.i -o hello.s，但完全没解释编译器从C代码到汇编语言经历了哪几个阶段。这就是典型的把工具当截图工具用，缺的是原理层面的解释。

反过来说，如果你能把每个命令输出的每一行都讲清楚它背后对应教材的哪个知识点，这个作业你想拿低分都难。作业本身就是在逼你把书上的知识"焊"到实际产物上。

1.3 我的实验环境与工具配置

我的机器是Ubuntu 22.04.3 LTS 64位虚拟机，分配了4GB内存和2核CPU。大作业用的核心工具如下，建议你提前确认版本，因为不同版本的输出会略有差异，报告里写清楚环境是基本素养：

对了，强烈建议你复用我这份模板清单里的hello.c版本，它是HIT大作业里比较经典的一个：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> int main(int argc, char *argv[]) { if (argc != 2) { printf("Usage: %s Name\n", argv[0]); exit(1); } printf("Hello %s, Welcome to HIT!\n", argv[1]); sleep(5); return 0; }

为什么选这个版本？因为它同时用到了argc/argv参数传递、printf格式化输出、sleep系统调用、exit退出，后面展开进程、信号、I/O、终止回收时全都能对上，一个程序把考点全占了。

2. 预处理与编译：从hello.c到hello.s，CPU不认if-else

2.1 预处理真正做的事：不只是展开头文件

预处理是编译流程的第一站，对应的命令是：

gcc -E hello.c -o hello.i

很多人对预处理的认知停留在"把头文件展开、把宏替换掉"，但其实它有四个明确动作：

1. 头文件展开：#include <stdio.h>会被整个文件内容替换掉，stdio.h里申明的printf、stderr、FILE结构体定义等会全部倒进来。
2. 宏替换与删除注释：#define定义的宏在预处理阶段完成文本级替换。注释则在预处理时被替换成空格。
3. 条件编译处理：#ifdef、#ifndef、#endif等指令决定哪些代码块保留、哪些丢弃。
4. 添加行号标记：预处理器会在生成文件中插入# 1 "hello.c"这样的行标记指令（line marker），方便编译器后续报错时定位到原始文件的行号。

你可以用一个命令直接验证展开规模：

wc -l hello.c hello.i

我第一次看到这个输出是震惊的：hello.c只有11行，hello.i有约18000行。为什么？因为stdio.h、stdlib.h、unistd.h及其内部嵌套包含的头文件全被展开了。

这里要强调一个关键认知：预处理完全是在文本层面操作，它不关心语法、不检查类型、不做任何语义分析。哪怕你在#define里写了完全不合法的符号，预处理器照样把它替换进去，报错是编译阶段的事。面试如果问"宏和内联函数的区别"，绕不开这一点：宏的展开发生在预处理期，无法进行类型检查，而内联函数是编译器行为。

2.2 编译：C代码是怎么变成汇编的

预处理的下游是编译，命令是：

gcc -S hello.i -o hello.s

-S选项告诉gcc只做编译，不做汇编和链接，输出结果是汇编代码文件。很多初学者以为编译器是"直接翻译"的，一个if对应一句cmp+jmp，其实完全不是。现代编译器的编译流程分至少六个阶段：

1. 词法分析：把源代码拆成单词流（token），比如printf、(、"Hello"、;分别归为标识符、左括号、字符串常量、分号。
2. 语法分析：根据C语言文法，把token流组织成语法树，比如识别出printf(...)是一个函数调用表达式。
3. 语义分析：做类型检查，比如argc != 2是整数比较、argv[1]的类型是char *。
4. 中间代码生成：生成与目标机器无关的中间表示（GIMPLE、RTL），方便后续优化。
5. 优化：这是最复杂也最有意思的阶段。比如你的printf("Hello %s, Welcome to HIT!\n", argv[1]);里参数个数固定，编译器不会真的走一次通用printf，而可能直接生成对printf的调用（默认不优化时），但开-O2后行为会变化。
6. 目标代码生成：把优化后的中间代码映射成目标架构（这里是x86-64）的汇编指令。

我建议你分别用-O0和-O2各编一次，然后对比hello.s的差异。默认gcc不开优化时，sleep(5)会被编译成一个简单的call sleep@PLT；开-O2后，编译器甚至会尝试等价变换。这能帮你直观理解"优化器"是真实存在的，不是教科书上的虚词。

2.3 读懂hello.s的几个重点：栈帧、传参、控制流

编译生成的hello.s是整个大作业里第一个需要你"精读"的文本。不要怕，只需要抓住几个关键点就能读明白。

入口与栈帧：

main: pushq %rbp movq %rsp, %rbp subq $32, %rsp

这三行是x86-64下每个函数开头典型的栈帧建立：保存旧的%rbp，令%rbp指向当前栈帧底部，然后分配32字节局部空间。这块空间用来存argc、argv以及可能溢出的临时变量。

参数传递：argc在-8(%rbp)，argv在-16(%rbp)，这是ABI规定的%edi和%rsi寄存器传入后由编译器安置到栈上的结果。后面调用printf时，你会看到：

movl -8(%rbp), %eax movq -16(%rbp), %rdx movq 8(%rdx), %rsi leaq .LC0(%rip), %rdi movl $0, %eax call printf@PLT

这里8(%rdx)就是argv[1]（argv[0]在偏移0，字符串数组每个元素是8字节指针）。%rdi放格式串地址，%rsi放argv[1]地址，%eax置0表示没有浮点参数——这是System V AMD64 ABI规定的函数调用约定。整段代码就是教科书上"过程调用"的活教材。

为什么要掌握这些：大作业的"编译"章节，核心指标就是你能不能把hello.s里的某一段汇编和C源代码逐行对应上。我在报告里是画了一张"源代码-汇编-含义"的三列对照表，这个做法考试评卷时很加分。

3. 汇编与链接：ELF里的那些细节，决定了你能不能答好"P2P"

3.1 从hello.s到hello.o：汇编器在干什么

汇编阶段命令：

gcc -c hello.s -o hello.o

汇编器的任务是把汇编指令逐条翻译成机器指令，并生成可重定位目标文件（relocatable object file）。为什么叫"可重定位"？因为此时文件里所有需要跳转的地址、需要引用的外部符号，都还没有确定最终地址，留待链接阶段填坑。

在x86-64 Linux上，hello.o是ELF（Executable and Linkable Format）格式。用readelf -h hello.o看它的ELF头，重点抓这几行：

• Magic：一长串十六进制数字7f 45 4c 46，对应ASCII字符\x7fELF。这不是乱码，是每个ELF文件统一的"身份证前缀"。
• Class: ELF64：64位ELF，对应的虚拟地址宽度是64位。
• Type: REL：可重定位类型。这个非常关键——文件还不能直接运行，里面到处是"待填的空位"。
• Entry point address: 0x0：因为这个文件没有入口地址，入口地址是链接器在链接完成后填进去的。

再用readelf -S hello.o查看节（section）表，你会看到一串熟悉的名字：.text（代码）、.data（已初始化全局数据）、.bss（未初始化全局数据）、.rodata（只读数据，比如字符串"Hello %s, Welcome to HIT!\n"就躺在.rodata里）、.symtab（符号表）、.rela.text（代码段的重定位信息）。

重点看符号表：

readelf -s hello.o

你会看到main符号是被定义的（GLOBAL DEFAULT），而printf、sleep、exit、puts这些符号标记为UND（undefined），意思是"这个符号在别的文件里定义，链接器你要负责帮我找到它"。这就引出了下一个大问题：链接器如何把"未定义"变成"已定义"。

3.2 链接：静态链接的符号解析与重定位

链接是把一个或多个目标文件（以及静态库、共享库）合并成一个可执行文件的过程，命令：

gcc hello.o -o hello

链接器做的事可以概括为三步：

1. 符号解析：把每个目标文件里引用的符号（比如printf）与它实际定义的地方关联起来。如果所有符号都能找到定义，链接通过；如果有一个符号在任何一个目标文件或库里都找不到，链接器报undefined reference to 'xxx'错误。
2. 空间分配：决定每个节在最终可执行文件里的虚拟地址。比如gcc默认情况下，.text节的起始地址是0x400000往上。
3. 重定位：修正文件中所有引用外部符号的指令，把原来"未知地址"的占位符改成实际地址。

你可以先做一个有意思的观察：hello.o里printf是被当成外部函数调用的，但如果你只链接hello.o而不带libc，链接器必然报错。为什么？因为printf的定义在C标准库里。链接器在-lc的动态库中找到了它。这里有个关键点需要区分：如果libc是以动态库（.so）形式链接的，那么printf的地址最终不是链接期确定的，而是要等到程序真正运行时由动态链接器决定。这就引出了PLT和GOT。

3.3 动态链接与PLT/GOT：Hello也逃不过"懒绑定"

以我Ubuntu 22.04的环境来看，gcc默认是动态链接libc的。用ldd hello能看到类似这样的输出：

linux-vdso.so.1 (0x00007fff...) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f...) /lib64/ld-linux-x86-64.so.2 (0x00007f...)

printf、sleep、exit的实现在libc.so.6里，这是一个在程序加载时才被映射进进程地址空间的共享库。为了保证"共享库的地址可以在每次进程运行时都不同"，程序不能直接写死函数地址，于是引入了ELF里的.plt（过程链接表）和.got（全局偏移表）。

用objdump -d hello反汇编你会看到：

call 400530 <printf@plt>

这不是直接调用printf，而是跳到PLT桩。PLT桩具体做了什么？第一回它会跳到GOT表项，恰好GOT表项初始值指向PLT的下一条指令，于是跳回PLT。跳到PLT之后会先把链接标识压栈，再跳到动态链接器的解析函数，让动态链接器去libc.so.6里找到printf的真实地址，写回GOT表项。第二次再调用printf时，GOT表项已经是真实地址，直接跳过去完成调用。这种机制叫延迟绑定（lazy binding），好处是程序启动时不用一次性解析所有符号，用到了才解析。

作业里对这一段的考察点通常是：为什么要发明PLT/GOT？答案可以分两层：一是共享库为了多进程共享代码，必须保证"位置无关代码"，代码里不能有绝对地址硬编码；二是延迟绑定优化了程序启动性能。这两个理由说全了，这题就拿满了。

4. 从进程视角看Hello的一生：fork、execve与虚拟内存

4.1 为什么要有进程：从"程序"到"运行中"的跨越

现在进入P2P的下半程。你敲下./hello HITer，Shell怎么让这个程序跑起来？两句话拆解：fork创建了一个子进程，execve把hello程序加载进子进程的地址空间。

先别急着背概念，对比一下这两个动作的本质区别：fork是"复制进程"，execve是"替换进程"。具体到hello场景，Shell进程调用fork()后产生一个几乎完全复制自身的子进程——子进程的代码段、数据段、堆、栈都和父进程一样。然后子进程马上调用execve("hello", ...)，这个调用会做四件事：

1. 删除子进程原有的用户态虚拟内存区域（包括刚才复制来的Shell的代码段、数据段、堆、栈）。
2. 映射hello文件的代码段、数据段、.rodata等段到新的虚拟地址。
3. 创建新的堆和栈。
4. 把程序计数器（%rip）设置为ELF头里e_entry字段指出的入口地址。我们用readelf -h hello看到的Entry point address: 0x401000，就是这个地址。从这一刻起，CPU开始执行hello的第一条指令，进程真正"活"了。

用一个对比理解这两个调用的分工：fork负责"生一个孩子"，execve负责"让孩子换一套记忆彻底变成另一个人"。两者合起来，才是我们在终端里运行一个程序的标准流程。

4.2 execve后的地址空间长什么样

用pmap或gdb的info proc mappings看一下hello进程的虚拟地址空间，大致是这个布局（从低地址到高地址）：

这个布局就是CSAPP第九章虚拟内存那一整章的现实投影。每个进程都有一个完整的、独立的虚拟地址空间。为什么不是直接访问物理内存？因为虚拟内存机制带来了隔离、共享、按需分配等一大堆好处。详细展开如下一小节。

4.3 虚拟内存与页表：Hello凭什么可以假装独占4GB内存

假设你的机器只有4GB物理内存，但每个进程的虚拟地址空间都有2^64那么大（理论上限）。hello进程根本用不了那么多，它只把用到的部分映射到物理内存上。这里的关键数据结构是页表。

• 虚拟内存被划分为固定大小的页（默认4KB），物理内存也以同样的页框大小划分。
• 每个进程有自己的页表，页表项记录虚拟页到物理页框的映射关系。
• CPU访问虚拟地址时，会先查页表。页表项里有一个有效位，如果该虚拟页还没有被映射到物理页框，就触发缺页异常，操作系统再从磁盘、或者从可执行文件里把内容加载进物理内存。

Hello进程运行时，那些"假装拥有"的地址空间，实际上只有一小部分是真的映射了物理页：比如.text代码页需要被加载到内存里执行，.rodata里的字符串需要被读取，栈顶那几页要在调用printf时使用。而地址空间里大片未分配的区间，页表项要么无效、要么根本不存在。

顺带一提，CSAPP大作业的"存储管理"章节常考一个细节：TLB（Translation Lookaside Buffer）。页表是存在主存里的，每次访存都要查询页表，那多了一次内存访问，性能损失太大。所以CPU在MMU（内存管理单元）里加了一个小而快的缓存，缓存最近的虚拟页到物理页的映射关系，这就是TLB。Hello里每次指令取指、每次数据访存，都在和TLB打交道。局部性好，TLB命中率高，程序就跑得快。

5. 运行时的异常控制流：Hello如何与用户交互并随时准备退出

5.1 CPU异常、中断与信号：进程运行中"意外"的来源

进程不是只按部就班地执行指令，它还要应对各种突发情况。CSAPP的异常控制流（ECF）体系可以分成四层：中断、陷阱、故障、终止。落到hello这个例子上，最重要的是陷阱（trap）和信号（signal）。

陷阱是程序主动请求操作系统服务的行为。比如printf最终要输出到终端，但hello进程不能直接操作终端硬件，它必须调用write系统调用。在x86-64 Linux上，这个动作会把程序从用户态切换到内核态，由内核完成真正的I/O操作后再返回用户态。你可以在另一个终端里跑：

strace -o hello.strace -f ./hello HITer

然后打开hello.strace，会看到一长串系统调用列表。重点找这两个：

execve("./hello", ["./hello", "HITer"], ...) = 0 write(1, "Hello HITer, Welcome to HIT!\n", 28) = 28

第一行是execve系统调用，第二行是printf背后真正干活的write——它把格式化好的字符串写到文件描述符1（标准输出），返回成功写入的字节数28。这比空谈"printf调用了write"要有说服力得多，你的报告里如果能配一张strace的实际输出，老师一眼就知道你真的跑过。

信号是内核向进程发送的异步通知。你在终端里按下Ctrl+C，内核向前台进程组的所有进程发送SIGINT；按下Ctrl+Z，发送SIGTSTP。对于默认处理方式：

• SIGINT的默认动作是终止进程，所以按Ctrl+C后hello直接结束。
• SIGTSTP的默认动作是挂起进程，所以按Ctrl+Z后进程停住，Shell会打印[1]+ Stopped ./hello，你可以用fg让它继续跑、用jobs查看任务列表。

大作业里这里有一个很容易玩出效果的实验：你自己写一个接收SIGINT的自定义信号处理函数，让程序在收到Ctrl+C时打印一行提示再退出，然后把signal()或sigaction()的使用和原理写进报告。CSAPP第八章讲信号处理讲得非常细，这章节的作业分析也是拉开差距的地方。

5.2 标准I/O与Unix I/O：printf的缓冲问题

在终端里跑./hello HITer时输出立即显示，但如果把输出重定向到文件：

./hello HITer > out.txt

你会发现out.txt里内容可能不会在进程结束前及时写入——这其实是stdio缓冲在起作用。printf是标准C库的带缓冲接口，它会先把数据写入到用户态缓冲区内，缓冲区满了、主动fflush、或者进程正常退出时，才把缓冲区内容交给write系统调用。而write是Unix I/O,是无缓冲的直接系统调用接口。

为什么CSAPP第十章要单独强调这个区别？因为如果面试题问"printf和write有什么区别"，标准回答就是：前者是标准I/O库的带缓冲函数，涉及用户态缓冲区和FILE数据结构；后者是系统调用，直接陷入内核。一个小实验可以验证：只调用printf("hello")不换行然后sleep(10)，观察它在终端上什么时候出现。这也是很多同学在报告里"结合运行现象"的加分点。

5.3 进程的休眠与调度切换

hello里的sleep(5)会把进程挂起。sleep同样是一个系统调用，内核将hello进程从运行状态切换到睡眠状态，并设置一个定时器。此时CPU不会空闲等待，而是去执行其他就绪进程，5秒后内核唤醒hello，将其放回就绪队列，等待调度器选中它。

CSAPP第八章的上下文切换机制在这一刻体现得最清楚：每次从用户态进入内核态、再从内核态返回不同进程的用户态，都是从一个进程切换到另一个进程。hello被切换出去时，它的寄存器上下文被保存在进程控制块（PCB）里；切换回来时，这些寄存器值被恢复。你可能觉察不到，但在这5秒里，hello的上下文已经在内核里进进出出不知道多少次了。

6. 进程的消亡与回收：Hello的最终归宿

6.1 main的return 0，到底经历了什么

hello跑完printf，执行到return 0;，然后进程终止。这个"终止"不只是函数返回那么简单。

main函数被C运行时库（crt）里的__libc_start_main调用。当main返回后，__libc_start_main会拿到返回值（这里是0），然后调用exit(0)。exit是C标准库函数，它做三件事：

1. 调用所有注册过的atexit函数（如果程序里注册了的话，顺序是后进先出）。
2. 刷新并关闭所有标准I/O流（所以前面说printf的缓冲数据在进程正常退出时会得到落盘机会）。
3. 调用_exit(0)系统调用，真正进入内核，通知内核"这个进程运行完毕"。

如果你用了exit(1)提前退出，前面两步仍然会执行，但main里的return就不再生效——这是return和exit的一个重要差异。

6.2 僵尸进程与wait/waitpid：你好比一颗"被遗忘的石子"

进程终止不等于进程被清理干净。进程变成僵尸（Zombie）的原因很经典：子进程先于父进程终止，内核会保留该子进程的少量信息（PID、终止状态、资源使用统计等），等待父进程来取。在父进程调用wait或waitpid之前，这个子进程一直处于僵尸状态。

对于./hello HITer，Shell作为父进程会立即回收子进程，所以僵尸状态极短，你几乎察觉不到。但如果你写一个不调用wait的父进程，并且让子进程先退出，再用ps aux看看，就会看到[hello] <defunct>——教科书上的僵尸真实出现了。

大作业一般会要求分析这里的回收机制。可以看一下：

ps -l

输出里的STAT列如果是Z就到僵尸了。回收动作的底层是waitpid系统调用，父进程请求内核把子进程的退出状态返回给它，内核才彻底释放进程描述符。CSAPP第八章把这一块的规则说得很细：僵尸进程无法被kill -9杀死，因为它的生命周期只取决于父进程是否调用wait。

6.3 完整的P2P生命周期一览

到这里，hello的一生可以画成一条完整链路：

• 写代码：hello.c
• 预处理：hello.i
• 编译：hello.s
• 汇编：hello.o
• 链接：hello（可执行文件）
• 加载：Shellfork+execve
• 运行：进程有了虚拟地址空间，页表、TLB、系统调用、信号、上下文切换轮番登场
• 终止：return 0→exit→_exit
• 回收：父进程waitpid，僵尸状态解除

每一步背后都有若干系统机制在支撑。只要你能把这条链路上的每一站用"命令+输出+原理"三件套讲清楚，你的大作业就已经是优秀水平了。

7. 大作业报告写作技巧与常见的坑

7.1 大作业的结构设计

HIT这套大作业报告一般建议包含：中英文摘要、引言、几个核心章节（分别对应预处理、编译、汇编、链接、进程、存储管理、I/O、信号、进程终止）、结论。但章节目录不要生硬地照抄教材目录。让章节名像"把hello的一生讲成故事"一样推进，比如：

• 第1章 概述：hello简介、环境与工具
• 第2章 编译的四重身份：预处理到汇编
• 第3章 从可重定位目标文件到可执行文件：链接的魔力
• 第4章 进程视角下的hello：加载、虚拟内存与存储体系
• 第5章 运行时交互与异常控制流
• 第6章 进程终章：终止、回收与僵尸问题
• 第7章 总结与感想

每个章节的内部逻辑，统一封装成"我执行了什么命令 → 关键输出是什么 → 这些输出对应教材的什么原理"。这条结构线在评卷老师那里辨识度极高。

7.2 实战命令清单：让报告里的每个截图都有意义

我不建议把所有readelf输出全截图贴上去，那样报告会变成一堆垃圾信息。挑关键的、能支撑原理的片段展示，并用语言解释"为什么这一步的输出长这样"。

• gcc -E hello.c -o hello.i：验证头文件展开（对比行数）。
• gcc -S hello.i -o hello.s：分析栈帧、参数传递、调用printf@PLT。
• gcc -c hello.s -o hello.o+readelf -h/S/s：观察ELF类型、节表、符号表UND项。
• gcc hello.o -o hello+readelf -h：观察入口地址变化与ELF类型从REL变EXEC/DYN。
• ldd hello：查看动态链接依赖。
• objdump -d hello：查看main的汇编与PLT跳转。
• gdb：在_start、main上打断点，查看寄存器、栈和虚拟内存映射。
• strace：跟踪系统调用，看到execve、write、nanosleep（sleep的底层）。
• ps/pstree：观察进程树和状态。
• wait/fork自定义实验：复现僵尸进程，用自己的代码验证回收。

7.3 最容易翻车的点

第一，把P2P写成了点对点网络。这几乎是每年都会发生的笑话级错误。标题里的P2P是Program to Process，不是Peer to Peer，这两个概念差着十万八千里。虽然网上搜"P2P"出来的绝大多数是点对点下载、点对点通信，但你写报告时必须从头到尾保持Program to Process的语境。

第二，命令结果和环境版本没写清楚。比如我gcc 11和gcc 12生成的汇编代码可能略有差异，readelf输出的字段排列也可能不同。你报告里的“本实验环境”至少要写清楚操作系统版本、gcc版本、binutils版本、处理器架构。这不是凑字数，这是复现实验的基础信息。

第三，对ELF的可重定位与可执行文件差异不敏感。很多人readelf -h完就丢一边，完全没有对比hello.o和hello的入口地址、类型变化。这两者的区别是整个链接章节的灵魂，务必对比写出来。

第四，原理和命令“两张皮”。比如贴了readelf -s hello.o的符号表，却解释不出为什么printf是UND、main是GLOBAL；贴了strace的系统调用列表却说不清trap和用户态/内核态切换。写报告时每贴一个输出，要在下面写不少于100字的原理说明，这是最直接有效的提分手段。

7.4 做完这个作业之后，你应该带走什么

如果你只是把这份大作业当一个苦差事应付过去了，我觉得挺可惜。因为这个P2P一旦你想透了，往后看很多问题都会不一样。比如你以后再遇到"C++的编译链接报undefined reference"，你会立刻意识到是链接阶段的符号解析出了问题；遇到程序退出时崩溃但打印都正常，你会想到是不是atexit处理函数或缓冲区刷新有问题；遇到gdb看进程内存布局一脸懵，你会想起来去查execve后的地址空间映射。这套"命令-观察-原理"的思维方式，比报告本身值钱得多。

我在写这份作业的时候，最大的感触是：计算机系统不是由一堆孤立概念堆起来的，而是一条完整的流水线，一个hello就足够串起所有环节。如果你做完之后也能建立起这种全链路视角，那这十几页报告就没白写。