Why Making a Debugger is So Hard! | The Standup (ft. Ryan Fleury)

Debuggers are only “hard” because they sit across two worlds at once: they must control a running program at a low level, yet present massive amounts of state in a fast, interactive UI. That mismatch helps explain why many developers fall back on printf-style instrumentation—and why a debugger can feel slower or unreliable when the tooling isn’t up to the job.

Ryan Fleury (of the RAD Debugger project) draws a direct line between logging and debugging: both collect information from a running program. The difference is the amount of work required to get that information. A debugger effectively runs alongside the program, gathering logs without permanently modifying the target—until it hits practical limits, at which point developers still add manual logging. So “printf vs debugger” isn’t a philosophical split; it’s mostly a performance and usability split.

The conversation then zeroes in on why debuggers often lose to printf in practice: many debuggers are slow or clunky, especially on Linux. Fleury argues that if debuggers were fast enough, they would beat instrumentation because they can collect the same data without the compile–run–edit loop. But when the UI and workflow are inefficient, the debugger’s theoretical advantage evaporates. He describes RAD Debugger’s goal as removing that choice—making data collection fast enough that developers don’t have to decide between “instrumentation” and “interactive inspection.”

A major technical bottleneck is stepping—advancing execution “over” a line of source code. Stepping isn’t a simple mapping from source lines to CPU instructions. Compilers can turn one line into many instructions, reorder or interleave code under optimization, and even stop in the middle of a line. To implement stepping, a debugger must translate source-level intent into instruction-level control while coordinating with the operating system’s scheduling and control-transfer mechanisms.

Fleury explains how the common approach uses trap instructions like x86’s int3 to force the program to interrupt and return control to the debugger. But each trap can trigger expensive round trips between user space and kernel space, making conditional breakpoints and fine-grained stepping dramatically slower—especially inside tight loops. He also outlines why recursive stepping is particularly nasty: stepping “over” a call in recursive code requires tracking stack behavior and return points, often turning the debugger into a state machine rather than a straightforward “next line” feature.

The project history behind RAD Debugger adds context: it began as a Linux-focused effort funded by Valve and RAD Game Tools, driven by the lack of strong debugging tools for game developers. Over time, the team built not just an engine but also a UI capable of visualizing complex runtime data.

That UI is where RAD Debugger tries to justify itself beyond raw breakpoints. Instead of forcing developers to dump data and re-parse it, it supports watch-window visualizers—turning pointers into tables, rendering memory as hex views, and even showing 3D geometry, textures, and bitmap previews live as execution steps. The key claim is speed and integration: a debugger feature only matters if it’s faster than printf-style workflows.

By the end, the central takeaway is pragmatic. Debuggers are “awesome if they’re good” and “useless if they aren’t,” and the hardest part isn’t just finding bugs—it’s building a system that can control execution precisely while presenting the right information quickly enough to beat manual instrumentation.