Epic Games Open-Sources raddebugger: A Native Debugger with a Redesigned Debug Info Format
> Project: EpicGames/raddebugger · C · ALPHA
Why Would a Game Company Rewrite the Debugger?
Imagine you're debugging a crash in a massive game engine. Visual Studio hangs — not a crash, literally frozen — because it's trying to parse a 4GB PDB file. You wait 20 minutes, watch devenv.exe's memory climb from 2GB to 12GB in Task Manager, and then it gives up and tells you "debug information could not be loaded."
This isn't an isolated case. When Epic Games engineers debug million-line-scale projects like Unreal Engine, the PDB format's 32-bit internal tables overflow — a scale nobody anticipated when the format was designed in the 1990s. PDB isn't bad; it's just being used at a scale its designers never imagined.
Epic's response wasn't filing an issue with Microsoft. Instead, they wrote their own debugger — and redesigned the debug information format along with it. Then they open-sourced everything.
The Trio: Debugger + Debug Info Format + Linker
RAD Debugger isn't one thing — it's three things bundled together:
1. RAD Debugger: A native, user-mode, multiprocess, graphical debugger. Currently Windows x64 + PDB only, with Linux + DWARF support planned. Written in C, not an Electron wrapper.
2. The RDI (RAD Debug Info) format: The core innovation. Instead of using PDB or DWARF directly, Epic designed its own debug info format. PDB and DWARF were designed for "human engineers viewing variables in an IDE"; RDI is designed for "fast loading and querying by a debugger." PDBs from existing toolchains can be converted to RDI on demand.
3. RAD Linker: A performance linker built for very large projects. In test cases (multi-GB debug info), linking is 50% faster than MSVC. It can also emit the RDI format directly, skipping the PDB→RDI conversion step.
The logic chain of the trio: the linker generates RDI → the debugger consumes RDI → the debugger never waits for PDB conversion. This is a complete redesign from source to consumer.
Why PDB Overflows
PDB's internal tables use 32-bit indices. When an executable's debug info exceeds a certain threshold, these tables overflow — not "get slow," but "break outright." You end up with a PDB that looks fine but is actually corrupted: the debugger reads mismatched function names and line numbers, or fails entirely.
This isn't Epic-specific. Anyone who has compiled a ten-million-line C++ project has hit it. Microsoft knows about the problem, but PDB is backward-compatible; changing the format would break every existing toolchain. Epic doesn't need backward compatibility — they only need their own debugger to work.
The RDI format is currently defined in code (src/lib_rdi/rdi.h and rdi.c), not as a standalone specification. That means it's still iterating rapidly and hasn't been frozen.
RAD Linker: Where the 50% Speedup Comes From
The linker is the most overlooked bottleneck in the build pipeline. Compilers parallelize easily — each .cpp compiles independently. But linking is serial — it merges all .obj files into one .exe.
RAD Linker's three optimizations:
- Multithreading: Uses all CPU cores by default. Thread count can be limited via
/rad_workers. - Large Pages: Off by default; enabling them reduces TLB misses for an extra 25% speedup. But Windows' large-page support is buggy, so they're recommended only inside Docker/VMs.
- No LTO yet: Link-time optimization isn't supported currently, but it's on the roadmap.
The Large-Page Memory Trap
The RAD Linker documentation contains a refreshingly honest warning:
> 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.
This is a rarely discussed issue: large pages fragment system memory. Every time the linker allocates large pages, Windows memory fragmentation worsens. After a few consecutive links, fragmentation prevents further large-page allocation, and a reboot is the only fix.
Epic recommends large pages inside Docker/VMs — the environment resets after each build, so fragmentation doesn't accumulate. This reveals an engineering reality: performance optimizations and system stability often conflict. Large pages look great in theory (fewer TLB misses), but in practice they can wreck system memory.
How It Differs from rr, WinDbg, and GDB
RAD Debugger occupies a unique position:
| Debugger | Mode | Target Users | Debug Info | |----------|------|--------------|------------| | GDB | CLI | Linux developers | DWARF | | WinDbg | GUI + CLI | Windows system programmers | PDB | | rr | CLI | Researchers needing reverse execution | DWARF | | RAD Debugger | GUI | Very large project developers | RDI (custom) |
RAD Debugger doesn't support reverse execution (rr's killer feature) or kernel debugging (WinDbg's territory). Its unique value is optimized debug-info loading for extremely large projects — PDB breaks at that scale; RDI doesn't.
Multiprocess debugging is another highlight. When debugging a game engine, you may need to inspect the main, rendering, audio, and networking processes simultaneously. RAD Debugger supports multiprocess debugging natively — no need to launch multiple debugger instances.
What ALPHA Means
The README states explicitly: The debugger is currently in ALPHA.
Epic's open-source strategy: release the tool first, let the community find bugs. They explicitly ask users to attach dump files, reproduction steps, and test executables when filing issues. This is not a "stable at launch" project — it's a project that needs community help to polish.
Currently Windows x64 only. Linux support is on the roadmap but unscheduled. If you're a Linux developer, right now you can only watch, not use.
The Bigger Picture: Toolchain Sovereignty
Epic open-sourcing a debugger is, in itself, more interesting than the debugger's technology.
Game companies usually treat toolchains as core competitive assets, rarely open-sourcing them. Epic open-sourced Unreal Engine, and now a debugger too. The logic: a toolchain's ecosystem value exceeds its secrecy value. As more developers adopt the RDI format, file issues on RAD Debugger, and contribute optimizations to RAD Linker, Epic's own internal toolchain benefits too.
This is the same pattern as Google open-sourcing Bazel or Meta open-sourcing Buck: turn internal tools into industry standards, then benefit from community improvements. The difference: Epic is doing it in debuggers — a more vertical domain than build systems.
RAD Debugger may never replace GDB or WinDbg. But if the RDI format gets adopted by other debuggers, it changes the debug-info format ecosystem. Formats matter more than tools — whoever controls the format controls the gateway to the toolchain.
---
RAD Debugger is currently ALPHA, Windows-only, and incomplete. But if you've ever been tortured by a 4GB PDB file, this is the first open-source project to seriously take on the problem of "debug info at scale." Epic isn't improving the debugger — it's redefining how debug information is stored.