简介：《深入理解计算机系统》第三版配套实验包是一份面向计算机系统学习者的实践资源，适合正在阅读原书或准备系统掌握底层原理的读者。实验包围绕书中经典实验展开，覆盖汇编语言、内存管理、缓存模拟、进程控制、编译器构造与安全攻防等核心主题，能帮助学习者把抽象理论落到真实可运行的C程序与实验环境中。资源为rar压缩包，共145个文件，约1.94MB，以C源码、PDF文档、txt说明文本、头文件、makefile构建脚本及Shell脚本为主，既包含实验代码和辅助工具，也有配套文档与操作提示，便于对照学习和环境搭建，目前已有1602人学习下载。包内可以看到二进制炸弹拆除、缓冲区溢出攻防、Shell实现、缓存模拟等典型CSAPP实验场景，能支撑从底层逆向到系统编程的多层次练习，配合pdf与txt资料，还能快速理解实验要求、掌握调试与验证思路，是一份值得系统研读的CSAPP实践合集。
1. CSAPP 第三版实验为什么值得你花一个月重做一遍
我第一次跑 Data Lab 而不是在《深入理解计算机系统》第三版上划线时，才意识到这本教材的精气神全在配套实验里。CSAPP 第三版实验包，是一组让“计算机系统”从抽象变成可复现事故现场的资源：位运算、缓冲区溢出、缓存模拟、堆分配器、Shell 编程，每个 lab 都对应书里一章的核心机制。秋招季很多系统岗位的问答素材，实际就是从这套实验抽出来的变形题。适合刚读完教材却写不出代码的初学者，也适合想补底层功底的开发老手。一个实验完整跑通的收获，抵得上反复看书三遍。
2. 环境搭建：先解决 Ubuntu 里的工具链，再碰实验包
2.1 为什么最终选择 Linux：评分脚本和内存检查器只认这套生态
这套实验自带 makefile 和 perl 评分驱动，设计初衷是 Linux 环境。Windows 上即便用 WSL，也会遇到/tmp权限、符号链接、32 位库缺失等一连串问题；macOS 上更麻烦，gcc实际是clang，部分汇编代码和-m32编译参数的行为不一致，bomb 和 attack 实验反汇编出来的指令风格也会有差异。
我一般建议装一个 Ubuntu 22.04 或 20.04 的虚拟机，分配 4GB 内存、两个以上 CPU 核心就够了。选 22.04 是因为它自带的 gcc 是 11.x，支持 C11，编译老实验包没有任何问题；20.04 的 gcc 9.x 也完全能跑。不要一上来就去追最新 24.04 的 gcc 13，遇到个别 lab 的驱动源码报编译警告升级成错误，那种一次配置半小时的体验很劝退。
有些实验需要编译 32 位版本，比如早期版本的 data lab 驱动，或者你想用-m32观察指针大小的变化。单纯装gcc不够，还需要gcc-multilib这个库，否则链接阶段直接报bits/libc-header-start.h: No such file or directory，之后你再怎么改 C 代码都白搭。
2.2 解压后的实验目录与各个实验的作用
下载到的实验包通常是一个 tar.gz 压缩文件，解压后能看到若干独立目录。一般包括 data、bomb、attack、cache、malloc、shell、proxy 这几组。data 对应第二章信息的位运算与浮点数表示；bomb 是汇编逆向通关；attack 是栈溢出与 ROP 注入；cache 是缓存模拟器和矩阵转置优化；malloc 是实现动态内存分配器；shell 是写一个微型 Unix Shell；proxy 是写一个并发 HTTP 代理。
每个 lab 目录内部结构高度一致：一个Makefile、一份讲义writeup、一个评分驱动脚本或二进制、若干.c/.h骨架源码，以及traces或target这类附属数据目录。拿到压缩包后，我习惯先用tar -xzf解压到~/csapp-labs下，然后逐个目录执行make，目的不是立刻写代码，而是确认每个 lab 的原始构建链路是通的。如果连默认代码都编不过，先检查是不是 gcc 版本或缺少 32 位库，别急着改实验代码。
2.3 一条命令装齐工具链并自检
在 Ubuntu 里执行以下命令：
sudo apt update sudo apt install -y build-essential gcc-multilib gdb valgrind gcc --version | head -1 make --version | head -1 gdb --version | head -1build-essential负责安装 gcc、make 和基础头文件；gcc-multilib提供 32 位编译支持；gdb是 bomb lab 的必备调试器；valgrind在 malloc lab 里检查内存错误，比你自己盯着指针找省力得多。最后三条--version命令是自检，确认工具链进入 PATH。
装完工具链后，进入 data lab 目录先执行一次make。如果看到生成btest、dlc这类可执行文件且无报错，说明环境合格。常见的一个坑是某些驱动脚本用/usr/bin/env python调 Python 2，但新版 Ubuntu 只有 Python 3，此时需要把脚本第一行的python改成python3，或者用ln -s /usr/bin/python3 /usr/bin/python做兼容，但后者容易引起系统级混乱，我更推荐直接改实验脚本第一行。
3. Data Lab 从 bits.c 到 btest：位约束、浮点坑与评分机制
3.1 dlc 这个“位操作白名单”到底在检查什么
Data Lab 的核心文件是bits.c，里面有十几个函数等着你填空。每个函数顶部都有注释说明允许使用的运算符，还有一条铁律：不能使用if、while、for、&&、||、?:，不能使用超过0xff的常量。这套限制初看很玄学，其实是逼着你用位运算表达逻辑分支。
dlc是官方自带的数据实验检查器，它并不是编译器，而是一个语法与操作符的静态检查工具。执行：
./dlc bits.c如果不输出任何报错，说明你的代码没有越界使用运算符。常见的违规行为，比如想判断一个整数是否为正数时写出了x > 0，dlc 会直接报illegal operator。我把 dlc 当作第一道闸门，写完一个函数就跑一次，避免积累一堆错误后再排查。它不会检查逻辑正确性，只检查“白名单”约束。
举个例子，实现“判断数值是否为负数”的逻辑：
int isNegative(int x) { return !!(x >> 31); }逻辑说明：算术右移保留了符号位，负数右移后结果是0xffffffff，再通过!!双重取反变成 0/1。参数说明：这里不能用x < 0，因为<不在允许运算符列表里；x >> 31在负数场景下依赖编译器对算术右移的实现，这本实验明确要求使用算术右移，所以可以依赖这个行为。
dlc通过后，下一步是btest做功能验证：
./btest -f isNegative-f参数指定只测某个函数，会输出函数名、测试用例和实际结果，如果不匹配会明确给出ERROR。整个文件的所有题目跑完，执行./driver.pl，它会调用 dlc 获取风格分，再调用 btest 获取正确性分，最后汇总一个总评。评分脚本的权重里，正确性占大头，风格分看代码行数是否够短，所以别写太啰嗦。
3.2 从零开始跑通一道位运算题的完整流程
以logicalShift为例，要求实现逻辑右移但不能直接用>>。我一般先写一个最朴素的版本：
int logicalShift(int x, int n) { int mask = ~(((1 << 31) >> n) << 1); return (x >> n) & mask; }逻辑说明：算术右移会在高位补符号位，所以要构造一个低32 - n位全为 1 的掩码，把符号扩展位清掉。1 << 31得到最高位为 1、其余为 0 的数，算术右移n位后，前面n+1位都是 1，再左移一位让第n位变为 0，最后取反得到口罩。参数说明：n的范围在输入中限定为 0 ~ 31，所以不需要处理n=32的极端情况。
写完立即跑：
./dlc bits.c ./btest -f logicalShift我在前几次练习时吃过一个亏：dlc是通过了，但btest报错，原因是1 << 31是未定义行为，gcc 在优化级别高时有把所有左移符号位场景改写成随机值的风险。后来我改成1 << 31前先加unsigned强转，或者直接用0x80000000常量，但常量超过0xff限制，于是采用方案：
int logicalShift(int x, int n) { int sign = (x >> n) & ~((1 << 31) >> n); return sign; }这个思路更稳妥：x >> n保留符号位扩展，再与一个“清除高位冗余”的掩码相与，避免未定义左移。实际开发中这类“编译器优化破坏位运算直觉”的问题很常见，Data Lab 就是让你提前体验。
3.3 浮点题目的隐藏坑：类型转换与舍入
Data Lab 后半部分要求处理float的位级表示，但函数入参是unsigned，你要自己解析符号位、阶码和尾数，不能直接做浮点运算。比如实现float_i2f，把int转成float的位模式。第一步要提取符号位，然后算绝对值，再找最高位的 1 来确定阶码偏移。
参数设计上，关键变量有三个：sign占 1 位，exp占 8 位，frac占 23 位。舍入是这里最容易翻车的地方，不只是简单截断，而是要考虑“向偶数舍入”。常见解法是先右移丢弃多余尾数位，再检查丢弃部分的最高位以及保留部分的最低位，决定是否需要加一。每次做完这种操作，用btest -f float_i2f单独验证一大圈边界值，尤其是0x7fffffff、0x80000000、幂次方边界等。
另一个坑是float_twice这类题，看起来简单的“指数加一”，其实还要处理三种特殊情况：阶码全 0 时应该把尾数左移一位；阶码全 1 时直接原样返回；无穷大和 NaN 也要保持原样。我在第一次实现时只处理了正常数，结果btest在边界输入上报了十多个错误。这类边界判断，正是教材第二章“浮点数表示”里讲的内容，只是实验把它变成了你必须手写的逻辑。
4. Bomb 与 Attack Lab：从反汇编到栈破坏的实操链路
4.1 GDB 断点三板斧：break、disassemble、x/w
Bomb Lab 是个二进制炸弹文件，里面包含 6 个 phase，每个 phase 读取一行字符串，正确则通过，错误则引爆炸弹。动手前先objdump -d bomb看反汇编，然后用 gdb 加载可执行文件：
gdb bomb (gdb) break phase_1 (gdb) run程序会停在第一个 phase 的入口，此时执行disassemble能看到这一小段汇编。phase_1通常先比较两个字符串地址，最常见的形式是调用strings_not_equal，然后根据返回值决定是否调用explode_bomb。
参数说明：break phase_1是在函数入口下断点；run启动程序，gdb 会在第一个断点暂停。继续用x/s 0x402400查看内存中某个地址里的字符串，x是“查看内存内容”的命令，/s表示按字符串格式输出。看到目标字符串后，把它写进答案文件，然后quit重启 bomb，输入该字符串进入下一阶段。
三条我常用的 GDB 指令组合：
(gdb) break *0x4012ab (gdb) x/20i $rip (gdb) x/wx $rspbreak *0x4012ab指的是在绝对地址下断点，适合对付那些没有符号的中间函数；x/20i $rip反汇编当前指令指针附近的 20 条指令；x/wx $rsp查看栈顶的 32 位值，在 phase 里查看局部变量时特别有用。很多时候 phase 答案就藏在一个栈变量的比较里，x/wx直接能看到这个数的十六进制表示。
4.2 objdump 反汇编与 strings 先扫后拆，少走一半弯路
Bomb 的六个 phase 难度递增，phase_2 和 phase_3 常涉及循环或分支跳转，phase_5 需要从字符数组里取索引，phase_6 是链表结构操作。我习惯先用objdump -d bomb生成一份完整反汇编到工程目录下：
objdump -d bomb > bomb.asm strings bomb > bomb.stringsbomb.asm是整个可执行文件的反汇编，bomb.strings是里面所有可打印字符串。这两份文件不是用来直接抄答案，而是给你一个全局地图：哪些地址被call了、哪些字符串被比较。常见套路里，phase_1调用的比较函数后面会跟着一条内存中的字符串地址，地址对应的内容往往正是答案；phase_5里会有一个字符数组索引的片段，你需要找到0x402780这类基址，根据索引值去bomb.strings里复原答案字符串。
phase_6 是最繁琐的一个，往往需要手动在纸上画出链表节点的顺序。我的做法是在 gdb 里打断点，逐个输出节点指针：
(gdb) break *0x4013d4 (gdb) x/3gx 0x6032d0这里的三个 8 字节值分别是value、next指针和节点顺序索引，直接打印出来按顺序排序，答案就是你通过调整输入让链表变得递减或递增的排列。这个过程本质上是逆向一个结构体数组，手写地址追踪比纯靠人脑记可靠得多。
4.3 Attack Lab 的注入与 ROP 边界：栈地址不是玄学
Attack Lab 是第三版相对于第二版最明显的变革，把原来的 buffer lab 从“直接往栈里塞汇编”升级成“攻击代码注入 + ROP 链构造”两个任务。首先需要确认目标文件和函数：
objdump -d ctarget | grep -A 20 "<getbuf>"ctarget是代码注入的目标程序，getbuf是你的攻击点，函数内部通常会分配一个 32 字节或更小的缓冲区，并且编译时禁用栈随机化，为了让实验可复现。输入攻击字符串时，重点是算出返回地址距离缓冲区开头的偏移。常见做法是在 gdb 里运行：
gdb ctarget (gdb) break getbuf (gdb) run -q (gdb) info frameinfo frame显示当前栈帧信息，包括Saved registers那一行，里面有rip保存在栈上的地址，用它减去rbp指向的栈帧基址，再扣除缓冲区本身的偏移，就能算出注入代码的起始位置。如果你偷懒不想算，另一个方法是直接p/x $rsp查看栈指针位置，在缓冲区内填充 nop 滑梯，返回地址指向 nop 序列中间，一样能命中你的 shellcode。
ROP 阶段不让你注入新代码，只能利用已有的 gadget。你需要熟悉几条常见指令：pop rdi; ret用于控制第一个参数，ret本身是栈指针跳转的推动器。搜索 gadget 时用 objdump 的-M intel参数：
objdump -d rtarget | grep -B 5 "pop %rdi"注意提示：rtarget的反汇编默认用 AT&T 语法，地址和寄存器顺序和 Intel 手册相反。用-M intel后阅读体验大幅提升。构造 ROP 链时，你需要连续放置多个 8 字节地址，每个地址指向一个 gadget，cook 值和参数也要写在栈上。这里最经典的错误是漏掉了ret指令，导致链条执行完一个 gadget 后飘到错误地址。
5. Cache Lab 与 Malloc Lab：性能敏感实验的避坑记录
5.1 Cache Lab 的模拟器：从 -s -E -b 参数到 LRU 更新策略
Cache Lab 分两部分，Part A 是实现一个缓存模拟器csim.c，Part B 是写一个矩阵转置优化函数。Part A 需要从命令行解析参数，模拟地址序列对缓存命中的影响。命令格式是：
./csim -s 4 -E 2 -b 4 -t traces/foo.trace参数含义：-s指定组数索引位的数量，实际组数是2^s；-E是每组行数；-b是块偏移位数；-t是 trace 文件路径。模拟器内部需要一个二维结构体数组，每个 cache 行包含valid、tag、lru_counter三个字段。每次访问地址时，先拆出 tag 和 set index，再遍历对应组的每一行：
void access_cache(unsigned long addr) { long tag = addr >> (s + b); int set_idx = (addr >> b) & ((1 << s) - 1); for (int i = 0; i < E; i++) { if (cache[set_idx][i].valid && cache[set_idx][i].tag == tag) { hit_count++; cache[set_idx][i].lru = ++time_stamp; return; } } miss_count++; // 找一个 lru 最小的替换它 int victim = find_lru(set_idx); cache[set_idx][victim].valid = 1; cache[set_idx][victim].tag = tag; cache[set_idx][victim].lru = ++time_stamp; }逻辑说明：addr >> (s + b)先清掉组索引与块偏移位，留下的就是 tag；(addr >> b) & ((1 << s) - 1)屏蔽掉高位 tag，只保留中间 s 位作为组索引。time_stamp每次访问都自增，这样最小 lru 值的行就是最近最少使用的那行，替换它即可。
Part B 的矩阵转置优化，核心是用分块来降低冲突未命中。经典参数是 8×8 分块，但在 32×32 矩阵上，直接照搬 8×8 可能因为缓存组映射关系反而更差。我建议先用csim-ref，也就是官方参考模拟器跑你自己的模拟器对比命中率曲线，再逐个分块大小试 4×4、8×8、16×16。优化转置时，读入和写出都要及时用完局部变量，避免重复访问刚写入的内存。
5.2 Malloc Lab：从隐式空闲链表到显式空闲链表，先跑通再优化
Malloc Lab 要求你在mm.c里实现mm_malloc、mm_free、mm_realloc和mm_checkheap，评分驱动会读取traces目录下的一批内存请求序列，跑完后计算空间利用率和吞吐量。最推荐的起步方案是显式空闲链表：用空闲块的头尾部存prev和next指针，分配时遍历链表找第一个符合大小且的块。
static block_t *find_fit(size_t asize) { block_t *bp = freelist_head; while (bp != NULL) { if (bp->size >= asize) return bp; bp = bp->next; } return NULL; }逻辑说明：空闲链表的每个节点都维护自己的块大小和前后指针，遍历到第一个满足条件的位置就返回。这属于 first-fit 策略，优点是分配速度快，缺点是容易产生大量小碎片，空间利用率偏低。参数说明：asize是已经对齐并加上头部开销后的实际请求大小，如果find_fit返回 NULL，说明堆内存不够，需要调用mem_sbrk扩展堆。
mm_free的关键不仅仅是归还块，而是立即做边界标记合并，把相邻空闲块拼成一个大块：
void mm_free(void *ptr) { block_t *bp = (block_t *)ptr - 1; bp->size |= 1; coalesce(bp); }这里ptr - 1是定位块头，size的最低位置 1 表示已分配，coalesce前后扫描相邻块的标志位，如果都是空闲就合并。我在写coalesce时踩过一次坑：合并时忘了更新链表指针，导致空闲链表出现环，mm_checkheap扫描直接死循环。所以实现时的顺序必须是：先摘除空闲节点、再修改大小、最后重新插入链表头部。
5.3 五个避坑记录：现象、原因与解法
这套实验做了两三轮，我把自己和周围人踩过的坑整理成五条，按“现象 → 原因 → 解决”的套路记录了。
第一条：btest报段错误，但dlc检查是干净的。现象是跑一定数量测试用例后进程崩溃，原因通常是数组越界或位运算得到的地址非法，比如把1 << 32这种写了进去，编译器按0处理，但逻辑全错。解决方式是先用-m32和-Wall重新编译，让警告浮出来，再用 gdb 在崩溃位置bt看调用栈，定位到具体函数。
第二条：cache 模拟器跑 trace 文件时命中率奇低，接近零。现象是-s 4 -E 1 -b 4这种参数下全 miss。原因往往是没有正确解析参数，-E的值默认成 0，或者(1 << s) - 1的括号写错导致集合索引被 tag 高位污染。解决方法是打印每个地址的拆分结果，手工验证第一个 trace 地址的 tag、set、block offset 是否与预期一致。
第三条：attack lab 里自己构造的返回地址在本地实验正常，放到另一台机器却段错误。原因是实验文档里那个栈地址依赖编译器和运行时布局。解决方式是不要硬编码地址，而是在getbuf内用 gdb 打印$rsp后动态计算，并把注入字符串中的地址统一替换成这个动态值。
第四条：malloc lab 本地跑mdriver -t traces/amptjp.rep一切正常，但 valgrind 报告 invalid read。现象是堆上有几个字节被越界读，原因是分配器的对齐计算少了 8 字节的头部，导致返回指针向低地址偏移。解决方式是把align4函数改成align8，确保返回值按 8 字节对齐，并在mm_checkheap里加边界检查。
第五条：修改代码后重新评分，分数没变甚至更低。原因是make clean没有执行，mm.o还是旧版本，评分驱动链接的是旧二进制。解决方式是在每个 lab 目录里固定执行make clean && make再跑评分脚本，把它写成一条命令，不要手动分开操作。
注意：Cache Lab 里的csim-ref是评判标准，你的模拟器输出必须和它完全一致，包括miss、hit、eviction的顺序和统计。先写一个不带任何优化的最小版本，跑通 5 个 trace 后，再考虑效率优化。
6. 进阶：一条命令批量评分与后续实验的推进顺序
6.1 用 shell 循环把整套实验串起来
把所有 lab 放在同一个根目录下，我总是建立一个run_all.sh脚本，内容是基于 make 的简单循环：
#!/bin/bash for lab in data bomb attack cache malloc; do echo "===== $lab =====" cd "$lab" || exit 1 make clean >/dev/null make >/dev/null 2>&1 || echo "build failed: $lab" if [ -x ./driver.pl ]; then ./driver.pl 2>&1 | tail -5 elif [ -x ./csim ]; then ./csim -s 4 -E 2 -b 4 -t traces/yi.trace fi cd .. done逻辑说明：每次先make clean再重新编译，保证评分用的二进制是刚生成的；根据 lab 类型选择不同的验证入口，data 和 bomb 用driver.pl，cache 用自定义的 trace 跑分，malloc 用mdriver，攻击实验则运行ctarget和rtarget的指定参数。参数说明：-s 4 -E 2 -b 4只是验证模拟器能否解析参数，真实的 Part B 评分脚本会传入更复杂的-s、-E组合，不要把这个参数当成唯一标准。
这个脚本的最大价值是避免“改了代码忘了重新构建”。我在第一次做 malloc lab 时连续两次因为没清旧.o文件而误判自己的分配器性能，后来强制所有 lab 走同一套 clean-build-run 流程，这个毛病就再没犯过。
6.2 Shell Lab 之后，再动手 Proxy Lab
如果你把前面几个 lab 都跑通了，接下来我推荐按顺序做 Shell Lab，再做 Proxy Lab。Shell Lab 要求你实现一个支持简单命令解析、重定向、管道和信号处理的 shell，它把进程管理、文件描述符、信号机制全部串在一起。这一部分反映的是教材第八章“异常控制流”和第十章“系统级 I/O”的综合能力，很多人在此之前对fork的理解停留在概念层面，写完 shell 才能真正体会到waitpid和execve之间的交互顺序。
Proxy Lab 是最后的硬仗，实现一个支持并发、正确解析 HTTP 请求、可能还要缓存小文件的代理服务器。它综合了多线程、锁、缓存、socket 编程和 HTTP 协议状态码处理。这部分做完，你会发现前面排过的 cache 模拟器的 LRU 思想在这里原样复用，但这次干的是真网络流量，调试难度更高。常见排查手段是telnet localhost 8080发一个原始 HTTP 请求，看代理转发是否带了正确的Host头，以及响应长度是否匹配。
6.3 一个检查习惯，值得你长期保留
从那以后，我每次拿到新的重构任务或学习项目，都会强制走一遍“先建立基线、再修改、再对比验证”的流程。具体到这套实验上，就是先把每个 lab 的 makefile 默认代码跑出原始分数，把它记录在案，然后再开始写自己的实现；每次改完代码只允许跑一次评分脚本，分数必须不低于基线，否则立即回滚查原因。这个习惯帮我筛掉了一大批“看似进步实则因为旧二进制被覆盖而误判”的假象。实验是死的，但系统知识是活的，希望你也能用这套资源把教材里的抽象段落变成亲自动手验证过的经验，希望帮到你。
本文还有配套的精品资源，点击获取
