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

Debugging is essential in programming, but the tools can be complex. RAD Debugger, developed by Ryan Flury and team, aims to revolutionize debugging on Linux and Windows by making it faster and more intuitive than traditional print debugging.

Print debugging involves inserting log statements to trace code execution. Ryan explains there's no fundamental difference between this and what debuggers do—they both collect program info, but debuggers automate and speed this process.

A debugger runs alongside your program, collecting logs without modifying the program's behavior. However, debuggers face technical constraints, especially in live environments, limiting how much they can alter program execution.

Many avoid debuggers because existing ones are slow or clunky, especially on Linux. RAD Debugger tackles this by aiming to be faster than print debugging, providing a smoother, more efficient experience for developers.

RAD Debugger originated from a collaboration between Valve and RAD Game Tools to improve Linux debugging for game development. Epic Games now owns RAD, continuing the project to create a robust cross-platform debugger.

Debuggers straddle a difficult boundary: they require deep system knowledge and sophisticated UI design. Casey notes debugger frontends are among the hardest UI challenges, combining low-level control with rich visualization.

Ryan joined RAD Debugger in 2021, focusing on UI and debug info parsing. The team also handles complex debug formats like PDB and DWARF, converting them into a unified format for easier cross-platform support.

Debugging large projects like Fortnite pushes debug info limits. PDB files can max out due to massive type info from templates and lambdas, highlighting the need for efficient debug formats like RAD's RDI.

Stepping through code is deceptively complex. A single source line maps to many scattered machine instructions. Debuggers must track instruction pointers, handle jumps, and manage recursive calls to step correctly.

To optimize stepping, debuggers use 'int3' one-byte trap instructions to interrupt execution at key points, avoiding slow single-instruction stepping and reducing kernel-user mode transitions.

User-level int3 handling, as Ryan suggests, would eliminate costly kernel transitions during debugging, speeding up conditional breakpoints and profiling. This feature would greatly enhance debugger performance.

Interpreted languages like JavaScript have different debugging challenges. Chrome DevTools is useful but can be unreliable and lacks advanced features like complex data visualization found in RAD Debugger.

RAD Debugger supports advanced visualizations: live 3D model previews, bitmap viewing, memory hex views, and customizable watch expressions that update dynamically as you step through code.

These visualizers save developers time by automating data inspection that would otherwise require manual logging or external tools. RAD Debugger integrates type info with visualizers for seamless debugging.

Stepping over recursive calls is tricky. RAD Debugger cleverly fakes return addresses to detect when a recursive call completes, avoiding expensive stack pointer checks on every recursion.

Debuggers must balance complexity and usability. RAD Debugger's goal is to be faster and more reliable than print debugging, making it a valuable tool for developers working in compiled languages.

Ryan Flury shares insights on RAD Debugger's development and invites developers to explore the project on GitHub. Follow him on Twitter @rflurry and visit rflurry.com for deep dives into debugger internals.

In summary, RAD Debugger is an ambitious project addressing the toughest challenges in debugging, combining low-level system control with advanced UI to save developers time and improve productivity.