NJU OS 调试 C 标准库

目录

• libc 调试的状态重构框架
• Debug Info 的语义映射作用
  • DWARF 的核心信息类别
• 调试器的程序状态重构机制
  • 1. PC 到源码位置的映射
  • 2. 当前帧到调用栈的展开
  • 3. 变量位置到变量值的恢复
  • 4. 优化对语义可恢复性的破坏
• libc 可调试性的前提
• printf 的用户态实现链条
• va_list 的 ABI 依赖性
  • 现代 ABI 下的参数分布
  • va_list 的遍历状态模型
• setjmp/longjmp 的现场保存与恢复
  • setjmp 的保存对象
  • longjmp 的恢复行为
  • 可恢复寄存器的 ABI 边界
  • 非恢复状态的范围
  • 自动变量不可靠性的来源
• gettimeofday 的 vDSO 快路径
• malloc 的用户态堆管理本质
  • malloc 的正确性与安全负担
• malloc Survey 的方法论启发
• 本页的统一主线
• 本节结论

libc 调试的状态重构框架

• 这节课的重点不是“会不会用 gdb 点几下”，而是理解一件事：
  调试器为什么能从一堆 PC/寄存器/内存 里，还原出“现在停在第几行、当前栈帧是什么、变量值是多少”。
• 对 libc 做这件事尤其有价值，因为它正好卡在 C 语言语义 / ABI / 汇编 / 系统调用 / 进程启动 的交界处。
• 这页笔记可以按下面这条链理解：

debug info-> gdb 能重构源码级状态-> 可以单步看 libc 的真实实现-> 进而看懂 printf / va_list / setjmp / vDSO / malloc

Debug Info 的语义映射作用

• 二进制文件里不只有指令和数据，还可以有额外的调试信息。

• 程序真正运行时的低级状态是：

  • PC/RIP
  • 通用寄存器、浮点/向量寄存器
  • 用户态地址空间里的内存

• 但人类和调试器想看到的是高级语义状态：

  • 当前源码文件和行号
  • 当前调用栈
  • 某个局部变量、参数、结构体字段的值

• DWARF 的作用就是提供一套“解释规则”，把低级状态翻译成高级状态。

• 它不是把“运行状态本身”存进二进制，而是记录：

  • 某个机器码地址对应哪一行源码
  • 在某个 PC 范围内，某个变量位于哪里
  • 如何从当前帧恢复调用者帧

DWARF 的核心信息类别

• .debug_line
  • 机器码地址到源码行号的映射。
  • next、断点停在某行、本质都是在做地址映射。
• .debug_frame 或同类 unwind 信息
  • 描述当前帧的栈展开规则。
  • backtrace、异常展开、profiling 都依赖它。
• .debug_info
  • 变量名、类型、作用域、结构体布局等语义信息。
• .debug_loclists
  • 描述“某个变量在某段 PC 范围内到底在哪里”。
  • 它可能在寄存器里，也可能在 CFA - 24 这样的栈槽里，还可能位置随着 PC 变化。

调试器的程序状态重构机制

• 核心模型：

真实状态 = PC + 寄存器 + 内存
debug info = 如何解释这份状态的规则
gdb = 按规则执行解释

1. PC 到源码位置的映射

• 调试器先拿当前 PC，去查 .debug_line。

• 得到：

  • 当前文件
  • 当前行号
  • 有时还能知道对应的列号、inlined call site

• 所以源码行本质上不是 CPU 的概念，而是 debug info 映射出来的概念。

2. 当前帧到调用栈的展开

• CPU 不会天然保存“调用栈字符串”。

• 它只有：

  • 当前 PC
  • 当前 SP
  • 若干寄存器
  • 栈内存里的返回地址和保存寄存器

• .debug_frame 之类的 unwind 信息会告诉调试器：

  • 当前帧的 Canonical Frame Address 在哪
  • 返回地址保存在什么位置
  • 哪些寄存器被保存到了栈上

• 调试器据此恢复调用者的 PC/SP/寄存器，重复这个过程，就得到 backtrace。

3. 变量位置到变量值的恢复

• 这是最容易被误解的一步。

• 变量 x 并不是天然“就在某个固定地址”。

• 尤其优化后，x 可能：

  • 在寄存器里
  • 一部分在寄存器、一部分在栈上
  • 被常量传播掉
  • 生命周期已经结束，根本没有可恢复的位置

• 所以调试器不是“扫内存找变量名”，而是：

  • 查当前 PC 对应的 loclist
  • 知道 x 现在应从哪个寄存器或哪个栈槽取
  • 再结合类型信息解释这串比特

4. 优化对语义可恢复性的破坏

• 因为“源码变量”和“机器状态”之间的一一对应关系被编译器破坏了。

• 典型现象：

  • 局部变量显示 <optimized out>
  • 单步时行号跳来跳去
  • 一个源码语句对应多个离散机器码位置
  • 调用栈里出现 inlining 造成的“逻辑帧”

• 所以调试 libc 或别的系统代码时，-Og -ggdb 往往比 -O2 -g 更友好。

libc 可调试性的前提

• libc 并不是黑盒魔法。

• 只要你手里的二进制和库带着足够的 debug info，gdb 就能一路跟进去。

• 这也是课上强调自己编译一份 musl libc 的原因：

  • 符号完整
  • 行号完整
  • 更适合单步

• 一旦能单步进 libc，很多原本抽象的接口就都能落回“寄存器和内存怎么变”。

printf 的用户态实现链条

• printf 最值得看的不是“会不会打印字符串”，而是它说明了：
  用户态库函数可以在完全不进入内核的情况下，先完成大量工作。

• 典型链条是：

printf-> vfprintf-> 解析 format string-> 按 ABI 读取 va_list-> 写入 stdio buffer / FILE 结构-> 必要时发出 write

• 所以 strace 里看到的是 write，但你代码里写的是 printf。
• 两者中间隔着整套用户态实现：
  • FILE 对象
  • 缓冲区
  • EOF / error 标志
  • 格式化逻辑
  • 锁和 flush 策略

va_list 的 ABI 依赖性

• 早期 cdecl 时代，很多人会写出这种 hack：

void foo(int n, ...) {intptr_t *vargs = (intptr_t *)&n;
}

• 这依赖一个隐含前提：所有后续参数都连续压在栈上。
• 现代 ABI 下这个前提通常不成立。

现代 ABI 下的参数分布

• 以常见的 x86-64 SysV ABI 为例：

  • 前几个整数/指针参数进 rdi/rsi/rdx/rcx/r8/r9
  • 前几个浮点参数进 xmm0-xmm7
  • 超出的部分才进栈

• 所以 va_list 的正确理解不是：

  • “把所有寄存器参数都挪到栈上”

• 而是：

  • 它提供一种遍历后续实参的机制
  • 编译器/ABI 会保证 va_start 和 va_arg 能按规则取到这些参数

va_list 的遍历状态模型

• 一个 va_list 背后通常要能描述：

  • 还没消费到哪个通用寄存器参数
  • 还没消费到哪个浮点寄存器参数
  • 栈上传参从哪里开始
  • 必要时，寄存器保存区在哪里

• 所以这里真正重要的不是语法，而是：
  printf 这种库函数已经深深依赖 ABI。

setjmp/longjmp 的现场保存与恢复

• setjmp/longjmp 是观察 calling convention 的极佳样本。
• 它们做的不是“回滚整个程序状态”，而是恢复一个合法的继续执行现场。

setjmp 的保存对象

• setjmp(env) 会把“以后还能回到这里继续执行”所需的寄存器现场保存到 env。
• 至少包括：
  • 栈指针
  • 返回位置 / 程序计数器相关信息
  • ABI 规定必须跨调用保持不变的 callee-saved 寄存器

longjmp 的恢复行为

• longjmp(env, val) 会把这些寄存器恢复出来。
• 然后伪造一次从 setjmp 返回：
  • 第一次 setjmp 返回 0
  • longjmp 回来后，setjmp 像是“第二次返回”，值变成 val，若 val == 0 则返回 1

可恢复寄存器的 ABI 边界

• 依赖具体 ABI。

• 但一般规律是：

  • 会恢复“恢复控制流所必须的寄存器”
  • 会恢复 callee-saved 寄存器
  • 不保证恢复 caller-saved 寄存器

• 所以一个很好的实验是：

  • setjmp 前给各寄存器染色
  • longjmp 前再改一遍
  • 看哪些值回来后被恢复

• 你会看到：

  • 恢复了的，通常就是 callee-saved
  • 没恢复的，通常就是 caller-saved / call-clobbered

非恢复状态的范围

• 它不会回滚整个内存世界。

• 所以：

  • 全局变量不会恢复旧值
  • static 变量不会恢复旧值
  • 堆内存不会恢复旧值
  • 文件偏移、fd 状态、锁状态也不会恢复

• longjmp 恢复的是“控制流和部分寄存器现场”，不是“时间倒流”。

自动变量不可靠性的来源

• 一个反直觉点是：

  • 全局变量在 longjmp 后通常保留修改后的值
  • 非 volatile 自动变量若在 setjmp 后被改动，则 longjmp 后值是未指定的

• 原因不是它被“回滚”了，而是编译器可能把它：

  • 放在寄存器里
  • 优化掉
  • 重排成源码直觉以外的形式

gettimeofday 的 vDSO 快路径

• 这部分用来回答一个常见问题：
  gettimeofday 到底有没有系统调用？

• 现代 Linux 上，经常不会真的触发一次 trap 进入内核。

• 常见路径是：

libc-> 查找 vDSO 中导出的入口-> 调用 vDSO 里的用户态代码-> 读取内核事先映射给进程的只读时间相关数据

• 所以：

  • 接口长得像普通 libc 函数
  • 语义上像“向内核取时间”
  • 实现上却可能完全在用户态完成

• 这说明 libc 不只是 syscall wrapper。

• 它也会根据平台机制，选择更便宜的路径来实现同一个 API。

malloc 的用户态堆管理本质

• malloc/free 表面上只有：

void *p = malloc(n);
free(p);

• 但操作系统并不提供“分配 37 字节”这种系统调用。

• 内核一般提供的是：

  • mmap
  • 历史上的 sbrk/brk

• 所以 malloc 的本质是：

  • 先向 OS 申请较大的虚拟地址区间
  • 再在用户态维护自己的堆内数据结构
  • 支持 split / reuse / coalesce / metadata / alignment

malloc 的正确性与安全负担

• 它要求在任意控制流路径上：

  • 所有该释放的块最终都能释放
  • 释放后不再访问
  • 多线程时还不能竞态

• 这就带来大量经典错误：

  • leak
  • double free
  • use-after-free
  • concurrent use-after-free

• 也正因为如此，后来才有：

  • RAII
  • managed runtime
  • ownership / borrowing
  • region / arena / GC 等更高层策略

malloc Survey 的方法论启发

• 课上引用的那篇 survey 最重要的观点不是“哪个 free list 更厉害”，而是：
  真正重要的是理解真实程序行为，而不是只盯着某个数据结构机制。

• 可以把它压成几句：

  • 研究长期过分关注 allocator mechanism，忽视 policy
  • 碎片本质上和对象死亡时序、phase behavior、size/order 规律有关
  • 真实程序不是随机 iid 请求流
  • allocator 的评估应该基于真实 trace，而不是过度依赖 synthetic random traces

• 这也解释了为什么：

  • 你一开始可能会想到 balanced tree
  • 但真正高质量的 allocator 研究，问题远不止“查找快不快”

• 更重要的问题是：

  • 什么对象应该尽量放在一起
  • 什么对象不该太早复用
  • 什么时候 coalesce
  • 如何兼顾碎片和 locality

本页的统一主线

• 这节课看起来同时在讲 printf、setjmp、vDSO、malloc，其实主线是统一的：

先用 debug info 把机器状态重新翻译成源码语义
再用 gdb 进入 libc
最后把这些“看似普通的 C 库接口”重新看成
ABI + 用户态状态机 + 内核接口 的组合实现

本节结论

• debug info 不是保存运行状态本身，而是保存“如何解释运行状态”的规则。
• gdb 能看见源码行、调用栈、局部变量，依赖的是 DWARF + 当前机器状态。
• printf 的关键不是输出字符串，而是它展示了 va_list + stdio buffer + write 这条完整用户态链路。
• va_list 不是“把所有参数都压栈”的老式 hack，而是 ABI 约束下对实参的统一遍历机制。
• setjmp/longjmp 恢复的是控制流现场和部分寄存器，不会回滚全局变量、堆和其他内存状态。
• gettimeofday 说明 libc 还会利用 vDSO 这种机制，避免不必要的系统调用。
• malloc 不是“向内核要一小块内存”，而是在用户态基于 mmap/sbrk 维护自己的复杂状态。
• 理解 libc 的最好方式不是背函数，而是沿着：

程序语义-> ABI-> 汇编和寄存器-> 进程地址空间-> 系统调用 / vDSO / 堆管理

一步步把抽象拆开。