从Hello程序看源码到进程：编译、链接与内存映射

简介哈工大计算机系统课程大作业文档面向正在完成CSAPP“程序人生—Hello生命周期”实验的本科生与自学者提供一份可对照的报告范例。压缩包共1个doc文件约6.44MB内容围绕Hello程序从源码到可执行文件、再到运行与终止的完整链路展开依次覆盖预处理、编译、汇编、链接、进程管理、信号与异常、内存管理及I/O管理等章节。文档中记录了Ubuntu下clang、gcc、as、ld等工具的使用命令并解析预处理中间文件的头文件展开与宏替换、汇编结果及可重定位目标文件结构配有环境工具、中间结果与各章小结便于按目录复盘实验步骤、理解底层机制并建立从源代码、编译工具链到操作系统机制的整体认识。已有358人学习适合用作课程报告结构参考、实验排错对照与期末复习材料。1. 一个 Hello 的一生几行 printf 凭什么惊动编译器、链接器和 MMU在终端敲下./hello的那个瞬间屏幕上只多出一行字。反直觉的地方在于这行字根本不是你写的那几行 C 直接送出去的。真正把字符送到终端的是被预处理展开过、被编译器翻译成汇编、被汇编器打包成 ELF、被链接器重定位过、又被页表映射进物理内存、最后经由一次系统调用交给内核的一串机器指令。计算机系统这门课很多地方叫它 CSAPP坚持用几十行的 hello 走完整条链路价值就在这里——它把「从源码到进程」这条平时看不见的流水线拆成了每一层都能停下来观察的标本。这条链路读通了段错误、链接错误、奇怪的空指针崩溃就不再是黑匣子。2. 预处理与编译hello.i 涨到三千行、hello.s 只剩几十行中间发生了什么拿到 hello 之后第一件让人发懵的事是中间文件的体积变化源码几十行hello.i三千多行hello.s又缩回几十行。这不是玄学它是「把环境搬进文件」和「把语义压进指令」两个反向操作的结果。搞清楚这两步后面看任何 C 程序的汇编输出都能对上号。2.1 预处理不是删注释是把整个运行环境搬进 .i 文件预处理阶段处理的只有以#开头的行。它做的事有四类把#include的头文件递归展开复制进来、把#define的宏按规则替换、按#if/#ifdef的条件决定哪段代码留下、把注释替换成一个空格保留行号。命令层面有两条等价路径一条走 gcc 驱动一条直接调预处理器# 走 gcc 驱动语义上等于 cpp gcc -E hello.c -o hello.i # 直接调用预处理器效果一致 cpp hello.c hello.i # 看文件规模和源码起始位置 wc -l hello.i grep -n hello.c hello.i | head -5wc -l出来的数字通常是三千出头而你自己写的main出现在接近末尾的位置。前面那三千行几乎全是stdio.h、stdlib.h、unistd.h递归展开带来的这三个头文件在 glibc 里互相引用最终拉进来几十个头文件、上千个类型定义、函数声明和宏。所以预处理最容易被误解的一点是——它不是「优化」它是在把你的源文件改造成一个自包含的翻译单元让后续的编译器不需要知道任何外部头文件的存在。hello.i里还有一种行标记很容易被忽略# 1 hello.c # 1 built-in # 1 command-line # 31 /usr/include/stdio.h 1 3 4这类# 数字 文件名是给编译器看的坐标它告诉编译器「从下一行开始这些内容来自哪个文件的第几行」。编译器报错时能精确指回hello.c:23靠的就是这些标记。如果手工改过.i文件却没同步行标记报错行号就会整体漂移这是排查时常见的不理解点。2.2 编译的五个阶段在 hello 上分别落在哪编译指从.i到.s。教科书把它拆成词法分析、语法分析、语义检查与中间代码生成、优化、目标代码生成五段落到 hello 上其实很好对应# 从预处理结果生成汇编 gcc -S hello.i -o hello.s # 也可以一步到位从源码直接到汇编 gcc -S hello.c -o hello.s # 打开常见警告能看到隐式类型转换这类语义层提示 gcc -S -Wall -Wextra hello.c -o hello.s词法分析把字符流切成 token比如int sleepsecs 2.5;会被切成int、标识符、、常量、;语法分析按 C 文法把这些 token 组织成语法树并建立符号表语义检查发现2.5是浮点却赋值给int给出隐式转换的提示并插入一条截断动作。所以sleepsecs的初值最终是 2 而不是 2.5这个截断发生在语义层不是运行时。优化阶段和-O级别直接相关这是很多人对着课本汇编对不上的根源。-O0下几乎每个变量都会落到栈上每次读写都真的访存一旦开到-O1以上循环变量可能被提到寄存器甚至整个循环被折叠。课本里那些「i 存在-4(%rbp)」的结论只在-O0成立。目标代码生成阶段负责把中间表示映射到 x86-64 指令、分配寄存器和栈帧、生成跳转标签。这一层是整章最值得逐行读的部分。2.3 寄存器、栈帧与寻址argc、argv、i 分别住在哪先看 main 的入口几行-O0下的典型形态main: pushq %rbp # 保存调用者的栈帧基址 movq %rsp, %rbp # 建立本函数的栈帧 subq $32, %rsp # 一次性开辟 32 字节局部空间 movl %edi, -20(%rbp) # argc 从第一个参数寄存器落到栈上 movq %rsi, -32(%rbp) # argv 指针落到栈上 cmpl $3, -20(%rbp) # if (argc ! 3) 的比较 je .L2 # 相等则跳过 if 体这段有两条关键信息。第一x86-64 的整数参数走寄存器第一个整型/指针参数在%edi64 位是%rdi第二个在%rsi返回值放在%eax/%rax。第二-O0下编译器会把参数从寄存器「溢出」到栈上所以你看到的是-20(%rbp)和-32(%rbp)而不是直接比较%edi。这解释了为什么课本里 argc 明明在%edi比较的时候用的却是内存操作数——中间隔了一次存储。argv是char *argv[]本质是二级指针在栈上占 8 字节。访问argv[1]时编译器不会「加 1」而是按元素宽度做比例变址movq -32(%rbp), %rax # 取 argv 首地址 movq 8(%rax), %rsi # argv[1]偏移 8 字节 movq 16(%rax), %rdx # argv[2]偏移 16 字节指针数组的步长由元素类型决定char *是 8 字节所以下标 i 对应偏移8*i。如果换成int argv[]步长就变成 4。这条「比例变址隐含在寻址模式里」的规则是理解 C 指针算术和汇编(%base,%index,scale)的同一件事。局部变量i分配在-4(%rbp)占 4 字节与argc的-20(%rbp)不冲突编译器按对齐规则依次排布。栈帧地址向低地址增长这是 x86 的约定subq $32, %rsp就是在「向下要空间」。2.4 控制转移if 和 for 在机器层是同一类东西C 里的if和for在汇编层没有专门的指令全部由比较 条件跳转 无条件跳转组合出来。看if (argc ! 3)的分支cmpl $3, -20(%rbp) # 计算 argc - 3设置条件码 je .L2 # ZF1 说明相等跳到 if 之外 # ... if 体打印用法、exit(1) movl $1, %edi call exitPLT .L2:cmpl做减法但不保存结果只更新 ZF/CF/SF/OF 这些条件码je读 ZF 决定跳不跳。注意编译器选择的是「条件取反跳出」的结构C 写的是「不等于 3 就进入」汇编写的是「等于 3 就跳过」。这种 guard 式布局能减少一次无条件跳转是控制流生成的常见手法。for (i 0; i 10; i)更典型movl $0, -4(%rbp) # i 0 jmp .L3 # 先跳到条件判断 .L4: call getcharPLT addl $1, -4(%rbp) # i .L3: cmpl $9, -4(%rbp) # i 9 与 i 10 等价 jle .L4 # 成立则回到循环体四段结构一目了然初始化、跳到条件、循环体 步进、条件判断回跳。i 10被写成i 9并非巧合这是编译器把严格小于转换成「小于等于上界」的规范化便于统一比较指令的选择。看到这一幕就明白C 的循环只是给人看的抽象机器里只有跳转。函数调用同样如此。call会把下一条指令的地址压栈返回地址然后跳转被调函数用ret弹出返回地址并跳回。main 结尾的leave等价于mov %rbp,%rsp加pop %rbp把栈帧完整还原。这些细节在.s里只有几行但它们构成了「函数调用为什么有开销」的物理基础。还有一处容易被当成错误的优化hello 里第一次printf(Usage: Hello ...\n)只有格式串、没有可变参数编译器会把printfPLT替换成putsPLT。这不是编译出错是编译器判断出「没有格式转换的 printf 等价于 puts 换行」后做的等价变换。第二次printf(Hello %s %s\n, ...)有%s就必须老老实实调printf。3. 汇编与链接hello.s 变成 hello.o 之后那些地址为 0 的指令在等谁汇编器把汇编文本翻译成机器码但此刻它还不知道printf最终在内存的哪个位置因为那要等链接器决定。于是它做了两件事把不确定的字段填 0 占位同时在.rela.text里记一笔「这里以后要改」。可重定位目标文件这个名字说的就是这种「半成品」状态。3.1 ELF 节头与符号表把代码、只读数据、可写数据分开放# 汇编.s - .o gcc -c hello.s -o hello.o # 看 ELF 头Type 应该是 REL可重定位 readelf -h hello.o # 看节头.text / .rodata / .data / .bss / .symtab / .rela.text readelf -S hello.o # 看符号表哪些符号已定义哪些是 UND未定义等链接 readelf -s hello.oreadelf -h里的Type: REL (Relocatable file)是判断文件性质最直接的依据可执行文件是EXEC或DYN。readelf -S列出的节里.text存指令、.rodata存字符串字面量和 const 常量、.data存已初始化的非 const 全局变量、.bss只占位不占文件空间未初始化或初值为 0 的全局变量。这里有一个流传很广的错误结论值得澄清字符串字面量确实进.rodata但像int sleepsecs 2;这样的普通全局变量标准 gcc 下是进.data的因为它可写。只有加了const才会进.rodata。写报告时如果照抄「全局变量在 rodata」用readelf -S一对照就会发现对不上。判断依据永远是工具输出不是记忆。readelf -s里能看到puts、printf、sleep、getchar这些符号的Ndx是UND意思是「本文件没定义链接时再说」。同时main的Ndx是 1指向.textBind是GLOBAL。这张符号表就是链接器的输入清单。3.2 重定位项call 后面那四个 0是留给链接器的坑位把 hello.o 反汇编会看到让人觉得「编译坏了」的输出objdump -d hello.o | head -300: e8 00 00 00 00 callq 5 main0x5 # 目标是 5其实是占位 0 5: bf 01 00 00 00 mov $0x1,%edi a: e8 00 00 00 00 callq f main0xfe8是call rel32后面 4 字节本应是相对偏移此刻全是 0所以 objdump 顺手算出一个「下一条指令地址」当成目标。真正的答案在重定位表里readelf -r hello.oRelocation section .rela.text contains 5 entries: Offset Info Type Sym. Name Addend 000000000001 000500000004 R_X86_64_PLT32 puts - 4 00000000000b 000600000004 R_X86_64_PLT32 printf - 4 00000000002b 000700000004 R_X86_64_PLT32 sleep - 4三个字段要读懂。Offset是「文件里哪个位置需要改」这里是.text内的 1、0xb、0x2b正好是每条call后四个字节的起始位置。Type是重定位类型R_X86_64_PLT32表示「按 PLT 相对寻址填 32 位有符号偏移」。Sym. Name Addend里的-4是加数。为什么固定是 -4因为 x86 的相对跳转指令偏移是相对于下一条指令的地址计算的。CPU 执行时 RIP 已经指向了call之后的第 5 个字节而链接器计算偏移时用的是待修改字段本身的地址 P。两者相差 4 字节所以要用S A - P这个公式令 A -4 来抵消。理解了这一点R_X86_64_PC32用于.rodata里的字符串地址、R_X86_64_PLT32用于外部函数调用就不再是死记硬背的对照表。3.3 链接布局为什么程序一加载就蹲在 0x400000# 链接hello.o 启动代码 库生成可执行文件 gcc -o hello hello.o # 看程序头段和入口地址 readelf -l hello | head -20 # 看可执行文件里的真实调用目标 objdump -d hello | grep -A2 mainreadelf -l里最要紧的两个字段Entry point address和若干LOAD段。典型布局是代码段从0x400000起依次排.init、.plt、.text、.rodata、.fini数据段从0x600000附近起排.data、.bss。可执行文件类型从REL变成EXEC开了 PIE 则是DYNcall后面那四个 0 被填成了真实的相对偏移。0x400000不是随便挑的。x86-64 上常见的 small code model 约定把代码放在低地址使得「符号地址」能塞进 32 位立即数从而让mov $symbol, %edi这类指令只需 5 字节而不是 10 字节。链接脚本里的默认布局本质上是在为指令编码的长度做取舍。链接过程本身分两步先做符号解析把所有.o和库里的UND符号与某个定义对上号再做重定位按公式把每个坑位填上。符号解析有个著名副作用——静态库是单遍扫描的如果你把-lm写在依赖它的目标文件前面链接器扫到-lm时还不知道有人要用就直接跳过了于是报undefined reference。这不是库不存在是顺序不对。3.4 动态链接GOT 和 PLT 是怎么把「不知道地址」变成「第一次慢、后面快」printf的实现不在 hello 里它在libc.so.6。链接阶段不会把 libc 的代码复制进 hello只记录一条依赖# 看动态依赖 ldd hello # 看动态段NEEDED、.interp 解释器路径 readelf -d helloreadelf -d里的NEEDED libc.so.6说明运行时要去加载这个共享对象.interp指向动态链接器如ld-linux-x86-64.so.2内核在execve时先把它加载进来由它负责把 libc 映射到进程地址空间。真正精巧的是调用路径。汇编里写的是call printfPLT其中PLT表示走过程链接表。第一次调用时.plt里对应条目会跳到.got.plt保存的地址而这个初始值指向「把符号索引压栈、跳回 PLT0 去解析」的一段桩代码解析完成后动态链接器把printf的真实地址写回.got.plt。第二次调用直接jmp *GOT几纳秒就完成。验证这套懒绑定机制有个很朴素的办法用 gdb 在main处断下x/gx看.got.plt里printf那格的值continue到第二次调用前再看一次两块地址会变。这比背「延迟绑定」四个字有用得多。4. 从 fork 到缺页hello 跑起来之后虚拟地址、页表、TLB 与信号接力前面所有工作产出的都是一个躺在磁盘上的文件。要让它变成进程shell 得先复制一个自己再把这个复制品的内存映像整个换掉。这一段是整条链路中最容易被跳过、也最能解释「为什么程序跑起来会崩」的部分。4.1 fork 与 execve进程映像怎么被整体替换bash读到./hello后调用fork()复制出一个几乎一模一样的子进程。复制不是把内存逐字节拷贝而是把父子的页表项都标成只读、指向同一批物理页写时复制。任何一方写某一页触发缺页内核才真正复制那一页。所以fork的开销和进程常驻集大小不成正比这是一次典型的用异常换性能的设计。随后子进程调用execve(./hello, argv, envp)内核做四件事删除当前进程用户空间的已有区域把旧的vm_area_struct链表清空映射私有区域把 hello 的.text、.data映射成私有可写/可执行区.bss用「请求二进制零」的匿名映射栈和堆初始长度为零映射共享区域把libc.so映射到共享区页表项指向同一份物理页所有进程共享设置程序计数器跳到 ELF 头里的入口点。入口点不是main而是_start。_start从栈上取出argc/argv再调用__libc_start_main由它完成 libc 初始化、注册退出处理最后才call main。所以课本里说「main 被谁调用」准确答案是启动代码不是内核。# 观察进程创建与 execve、内存映射、信号 strace -f -e traceprocess,memory,signal ./hellostrace输出里能看到execve(./hello, ...)成功返回、随后的brk/mmap申请内存、以及进程退出时的exit_group。这条时间线就是论文里「P2PProgram to Process」的实证。4.2 VA 到 PA段式、四级页表、TLB、Cache 的接力x86-64 上mov 0x601038, %eax里的地址叫逻辑地址先经段式管理变换成线性地址也叫虚拟地址。平坦模型下所有段基址都是 0段式管理形同虚设但它没被删掉因为段选择符还承载着特权级检查。真正的映射在分页。48 位虚拟地址被切成 5 段9 位页全局目录索引、9 位页上级目录、9 位页中间目录、9 位页表索引、12 位页内偏移。每一级表有 512 项每项 8 字节一页 4KB2 的 12 次方。四张表串起来才能把一个虚拟地址翻译成一个物理页帧号。为什么不用分段因为段是变长的分配和回收都会产生外部碎片粒度也太粗页是定长 4KB天然支持按需调页、写时复制、共享映射和按页设权限只读/可写/可执行。代价是每次访存理论上要走四次内存读表所以有了 TLB——它缓存最近的页表项命中时一次周期级查询就够未命中才走页表遍历page walk。再往下一层是 Cache。物理地址的低位决定落在哪个 set一次访存会把整条 64 字节的 cache line 拉进来。这意味着 hello 里读一个int其实拉进了 16 个 int也意味着顺序遍历数组比随机跳着访问快得多——局部性原理在硬件层的直接体现。这条链路可以概括成一句话程序里写的地址永远是虚拟的物理内存在硬件里由 MMU 一级一级查出来TLB 和 Cache 是两级加速缓存。4.3 缺页与信号崩溃和 Ctrl-C 走的是同一个入口当 CPU 访问一个虚拟页、而页表项标记为「不在内存」时会触发缺页异常。内核的缺页处理程序先判断这次访问是否合法如果该地址落在已登记的vm_area_struct里就分配一个物理页帧或直接映射零页、从磁盘读入内容、更新页表项然后返回用户态重新执行那条指令如果地址压根不在任何合法区域内核就给进程发SIGSEGV进程默认动作是终止并打印段错误。注意「合法但不在内存」和「非法访问」在硬件层是同一个异常区分全靠内核查表。这就是为什么调试空指针时看到的是「信号」而不是「异常」——异常已经被内核翻译过了。SIGINT走的是另一条路。终端驱动在收到 Ctrl-C 时给前台进程组发信号内核在进程的待处理信号集合里置位并在进程即将从系统调用或异常返回用户态时检查要么执行默认动作终止要么把栈帧改成调用用户注册的 handler。所以 hello 里sleep(2)期间按 Ctrl-C进程会在睡眠被中断后立刻响应而不是等循环跑完。4.4 I/Oprintf 为什么最后变成一个 writegetchar 为什么要等回车printf不是系统调用它是 stdio 库函数。它把格式化的字节先拼进一个用户态缓冲区凑够一定量或遇到换行才交给内核。终端字符设备通常是行缓冲遇\n就刷重定向到文件时变成全缓冲默认 4KB 才刷。刷的动作才是write(1, buf, n)通过syscall指令进入内核经 VFS 层交给终端驱动。这解释了两个常见困惑。第一strace ./hello out.txt里看不到每次 printf 都对应一次 write因为全缓冲下最后只刷一次。第二程序崩溃前打印的内容丢了因为那部分还在用户态缓冲里没交给内核。getchar反过来走读路径它从 stdin 的缓冲区取一个字节缓冲区空了就发read(0, ...)一次读一大块。终端在行模式下read要等到回车才返回所以 getchar 看起来「卡住了」其实卡在内核等行结束符。至于 hello 里那个printf(Usage: Hello ...\n)前面说过编译器把它换成了puts。puts会自己补一个换行同样走缓冲、同样落到 write。一条看起来简单的输出语句背后是「编译器优化 → 用户态缓冲 → 系统调用 → 内核 VFS → 设备驱动」五层这大概就是 hello 这个程序最值得被拆开看的原因。5. 排查与避坑hello 这条链路上最容易翻车的五处细节这条链路每一步都有工具可查但工具的默认行为和课本的叙述常常有落差。下面五条是实际动手时最容易卡住的地方按现象、原因、解决三段记下来。5.1 反汇编 hello.o 看到 call 目标是个小数字以为编译坏了现象objdump -d hello.o里所有call后面都跟着5 main0x5、f main0xf这种看起来像「跳到自己」的目标对比可执行文件里的call 400410 putsplt完全不同。原因可重定位目标文件还没做重定位call rel32的 4 字节偏移字段是 0 占位。objdump 只是忠实地把「下一条指令地址」当目标显示出来它并不知道那里将来会被填成什么。解决先用readelf -r hello.o看重定位表确认每个Offset与反汇编里的字节位置对得上再用公式S A - P手工验算一条链接后用objdump -d hello看同一条指令被填成什么两边对照占位与填充的关系就彻底清楚了。5.2 ATT 语法和 Intel 语法混着看把操作数顺序搞反现象课本写mov %rsp, %rbp你在某份资料里看到mov rbp, rsp以为两者等价或者对着 objdump 输出判断「把 rsp 赋给 rbp」还是反过来时反复横跳。原因GNU 工具链默认输出 ATT 语法操作数顺序是「源, 目的」Intel 语法是「目的, 源」。另外寄存器带不带%、立即数带不带$、间接寻址用()还是[]两套语法都不同。解决全程锁定一种语法。用objdump -d -M intel hello或gcc -S -masmintel hello.c统一成 Intel 风格注释里也统一写「目的 ← 源」避免同一份笔记里两套写法打架。5.3 预处理后行号对不上或者宏明明定义了却像没生效现象打开hello.i发现自己的源码跑到三千行开外报错行号指向莫名其妙的位置或者手工改过.i后编译错误提示指向的文件名和行号完全对不上。原因hello.i前面是递归展开的头文件你的代码只是被追加到末尾。而# 数字 文件名这种行标记是编译器的定位依据删除或改写它们报错位置必然漂移。宏没生效则多半是#define出现在使用点之后或条件编译的宏分支没被选中。解决用grep -n ^# .*hello.c定位自己代码在.i里的真实位置排查宏时用gcc -E -dM hello.c打印所有生效的宏定义比一行行翻.i快得多。想保留全套中间文件用gcc -save-temps hello.c.i、.s、.o一次性留全。5.4 静态库链接报 undefined reference库明明装了现象加了数学库之后仍报undefined reference to powldd也查不到libm但系统里确实有这个库。原因链接器对静态库是单遍从左到右扫描的。gcc -lm hello.o -o hello中扫到-lm时还没遇到hello.o不知道有符号要用于是整个库被跳过。解决把库放在依赖它的目标文件之后gcc hello.o -lm -o hello。多个静态库之间有依赖时按依赖关系从被依赖者往依赖者排或直接用--start-group/--end-group包住。另外要区分-L指定搜索路径和-l指定库名这两个写反了也会报同样的错。5.5 用 sleep 配合 Ctrl-C 观察信号输出顺序却乱了现象在 hello 里加了几句 printf中间sleep(2)按 Ctrl-C 之后发现某些本应先打印的内容反而出现在后面或者干脆没打印出来。原因stdio 缓冲在作怪。输出重定向到文件时是全缓冲进程被信号终止时用户态缓冲里的内容会丢失终端下是行缓冲但如果最后一句没带换行同样留在缓冲里。解决调试期在关键位置加fflush(stdout)或者用setvbuf(stdout, NULL, _IONBF, 0)关掉缓冲用strace -e tracewrite观察真正的 write 时机缓冲区里有没有货一目了然。这个坑在观察信号处理、进程终止顺序时尤其容易踩。6. 用几十行程序走完整条链路这个取舍值不值用 hello 做标本有个明显的好处它把「可观测性」的成本压到了最低。程序足够小你能把.i的每一段、.s的每一行、.o的每一条重定位、可执行文件的每一个段、strace的每一次系统调用都完整看完而不会被业务逻辑淹没。这种「全链路可见」是任何真实项目都给不了的。但取舍也很清楚hello 隐藏了大量真实系统的复杂度。它没有多线程所以看不到线程栈和 TLS只有一个翻译单元所以看不到符号冲突和弱符号依赖极少所以看不到版本脚本和符号版本跑完就退出所以看不到长时间运行下的内存碎片和页回收。真拿它当「计算机系统全景图」容易产生「一切都线性的」错觉。我的验证习惯是把同一件事用三种工具交叉确认。比如「printf 到底走到哪」汇编层看是printfPLT还是被优化成putsPLT动态层用readelf -d确认libc.so.6被依赖、objdump -d -j .plt看 PLT 条目运行层用strace -e tracewrite看真正的写调用发生在什么时刻、写多少字节。三者对不上说明我对某一层的理解有偏差而不是工具错了。从那以后我每次读一个陌生的二进制都强制走一遍「readelf -h看类型 →readelf -l看段和入口 →objdump -d看关键调用 →strace看运行时行为」这四步哪怕只是想知道它为什么启动慢。这套顺序不能保证每次都找到答案但能保证我不会在错误的抽象层上瞎猜。希望帮到你。本文还有配套的精品资源点击获取