Epic Games 开源原生调试器：raddebugger 把调试信息格式重做了一遍
你正在调试一个巨型游戏引擎的崩溃。Visual Studio 挂了——不是崩溃，是字面意义上的卡死，因为它在尝试解析一个 4GB 的 PDB 文件。你等了 20 分钟，任务管理器里 devenv.exe 的内存占用从 2GB 涨到 12GB，然后它放弃了，告诉你"调试信息无法加载"。
目录
Epic Games 开源原生调试器：raddebugger 把调试信息格式重做了一遍
项目：EpicGames/raddebugger · C · ALPHA
一个游戏公司为什么要重写调试器
你正在调试一个巨型游戏引擎的崩溃。Visual Studio 挂了——不是崩溃，是字面意义上的卡死，因为它在尝试解析一个 4GB 的 PDB 文件。你等了 20 分钟，任务管理器里 devenv.exe 的内存占用从 2GB 涨到 12GB，然后它放弃了，告诉你"调试信息无法加载"。
这不是个例。当 Epic Games 的工程师在调试虚幻引擎这种千万行级别的项目时，PDB 格式的 32 位内部表会溢出——这是 1990 年代设计格式时没人想到的规模。PDB 不是不好，是它被用在了设计者从未设想过的尺度上。
Epic 的回应不是给微软提 issue，而是自己写了一个调试器，连调试信息格式一起重做。然后开源了。
三件套：调试器 + 调试信息格式 + 链接器
RAD Debugger 不是一个调试器，是三个东西打包在一起：
1. RAD Debugger：原生、用户态、多进程、图形化调试器。目前只支持 Windows x64 + PDB，但计划扩展到 Linux + DWARF。用 C 写的，不是 Electron 套壳。
2. RDI（RAD Debug Info）格式：这是核心创新。Epic 没有直接用 PDB 或 DWARF，而是设计了自己的调试信息格式。PDB 和 DWARF 是为"人类工程师在 IDE 里看变量"设计的，RDI 是为"调试器快速加载和查询"设计的。现有工具链的 PDB 会被转换成 RDI 按需使用。
3. RAD Linker：一个性能链接器，专门处理超大项目。在测试用例中（调试信息数 GB），链接速度比 MSVC 快 50%。它还能直接生成 RDI 格式，跳过 PDB→RDI 的转换步骤。
三件套的逻辑链是：链接器生成 RDI → 调试器消费 RDI → 调试器不需要等 PDB 转换。这是一个从源头到消费端的完整重新设计。
为什么 PDB 会溢出
PDB 格式的内部表用 32 位索引。当一个可执行文件的调试信息超过某个阈值时，这些表会溢出——不是"变慢"，是"直接坏掉"。你拿到一个看起来正常但实际数据错乱的 PDB，调试器读出来的函数名和行号对不上，或者干脆读不出来。
这个问题不是 Epic 独有的。任何编译过千万行级别 C++ 项目的人都遇到过。微软知道这个问题，但 PDB 是向后兼容的，改格式意味着破坏所有现有工具链。Epic 不需要向后兼容——他们只需要自己的调试器能跑起来。
RDI 格式目前定义在代码里（src/lib_rdi/rdi.h 和 rdi.c），不是一份独立的规范文档。这意味着它还在快速迭代中，没有冻结。
RAD Linker：50% 提速是怎么来的
链接器是编译流程里最容易被忽视的瓶颈。编译器可以并行——每个 .cpp 文件独立编译。但链接器是串行的——它要把所有 .obj 文件合并成一个 .exe。
RAD Linker 的三个优化点：
- 多线程：默认用满所有 CPU 核心。可以通过
/rad_workers限制线程数。 - 大页（Large Pages）：默认关闭，开启后减少 TLB miss，再快 25%。但 Windows 对大页的支持有 bug，建议只在 Docker/VM 里用。
- 跳过 LTO：目前不支持链接时优化，但这是路线图上的项目。
大页内存的陷阱
RAD Linker 的文档里有一段很诚实的警告：
Large pages are off by default, since Windows support for large pages is a bit buggy; we recommend they only be used in Docker or VM images where the environment is reset after each link. In a standard Windows environment, using large pages otherwise will fragment memory quickly, forcing a reboot.
这是一个很少被讨论的问题：大页内存会碎片化系统内存。每次链接器分配大页，Windows 的内存碎片化就加剧。连续跑几次链接后，系统内存碎片化到无法再分配大页，只能重启。
Epic 的建议是在 Docker/VM 里用大页——每次构建后环境重置，碎片不会累积。这揭示了一个工程现实：性能优化和系统稳定性经常冲突。大页在理论上很好（减少 TLB miss），但在实践中会搞坏系统内存。
和 rr、WinDbg、GDB 的区别
RAD Debugger 的定位很特殊：
| 调试器 | 模式 | 目标用户 | 调试信息 |
|---|---|---|---|
| GDB | 命令行 | Linux 开发者 | DWARF |
| WinDbg | 图形+命令 | Windows 系统程序员 | PDB |
| rr | 命令行 | 需要反向执行的研究者 | DWARF |
| RAD Debugger | 图形 | 超大项目开发者 | RDI（自定义） |
多进程调试是另一个亮点。调试一个游戏引擎时，你可能需要同时看主进程、渲染进程、音频进程、网络进程。RAD Debugger 原生支持多进程，不需要开多个调试器实例。
ALPHA 意味着什么
README 里明确标注：The debugger is currently in ALPHA.
Epic 的开源策略是：先把工具放出来，让社区找 bug。他们明确要求用户提交 issue 时附带 dump 文件、复现步骤、测试可执行文件。这不是一个"发布即稳定"的项目，是一个"需要社区帮助打磨"的项目。
目前只支持 Windows x64。Linux 支持在路线图上但没排期。这意味着如果你是 Linux 开发者，现在只能看不能用。
更大的图景：工具链自主权
Epic 开源调试器这件事，本身比调试器技术更有意思。
通常游戏公司的工具链是核心竞争力的一部分，不轻易开源。Epic 开源了虚幻引擎，现在又开源了调试器。逻辑是：工具链的生态价值 > 工具链本身的保密价值。当更多开发者用 RDI 格式、给 RAD Debugger 提 issue、为 RAD Linker 贡献优化时，Epic 自己的内部工具链也会受益。
这和 Google 开源 Bazel、Meta 开源 Buck 是同一个模式：把内部工具变成行业标准，然后从社区的改进中获益。区别在于，Epic 做的是调试器——一个比构建系统更垂直的领域。
RAD Debugger 可能不会取代 GDB 或 WinDbg。但如果 RDI 格式被其他调试器采纳，它就改变了调试信息格式的生态。格式比工具更重要——谁控制了格式，谁就控制了工具链的入口。
RAD Debugger 目前还是 ALPHA，Windows only，功能不完整。但如果你曾经被 4GB PDB 文件折磨过，这是第一个认真对待"调试信息规模"这个问题的开源项目。Epic 不是在改进调试器，是在重新定义调试信息的存储方式。