GDB
By the GNU Project
GDB, the GNU Debugger, is a command-line debugger for compiled programs written in languages such as C, C++, Fortran, and others, that lets developers pause execution, inspect and modify memory and variables, step through code line by…
Definition
GDB, the GNU Debugger, is a command-line debugger for compiled programs written in languages such as C, C++, Fortran, and others, that lets developers pause execution, inspect and modify memory and variables, step through code line by line, and analyze crashes to find the root cause of bugs. It is one of the most widely used debuggers on Unix-like systems and ships as a standard tool alongside the GNU Compiler Collection.
Overview
GDB solves the problem of understanding what a compiled program is actually doing at runtime, which is difficult to determine from source code alone once a program crashes, hangs, or produces incorrect output far from the line that caused the problem. Before interactive debuggers like GDB became standard, developers relied heavily on print statements and manual reasoning, which is slow and often insufficient for problems like memory corruption or race conditions. Mechanically, GDB works by attaching to a running process or loading an executable along with its debug symbols, typically produced by compiling with a flag like `-g`, which map machine instructions back to source lines and variable names. From there, GDB can set breakpoints that pause execution at a specific line or function, single-step through instructions or source lines, print or change the value of variables and memory, walk the call stack to see how the program reached its current state, and analyze core dump files generated after a crash to reconstruct what happened without needing to reproduce the failure live. Among debuggers, GDB is the default choice on Linux and many other Unix-like systems, particularly for C and C++ development, and is the debugging backend many IDEs (including Visual Studio Code and CLion) drive under the hood rather than implementing their own. LLDB, part of the LLVM project, serves a similar role on macOS and for Clang-based toolchains and has increasingly competed with GDB, offering a more modern internal architecture, though GDB retains broader target and language support built up over decades. In practice, developers use GDB directly from the command line for quick debugging sessions, embed it as the backend of graphical IDE debuggers, use it for remote debugging of embedded systems over a serial or network connection via gdbserver, and rely on it to analyze crash dumps collected from production or QA environments to diagnose failures after the fact. GDB's main friction points are its command-line interface, which has a steep learning curve compared to graphical debuggers, and its reliance on compiled-in debug symbols, meaning optimized release builds without those symbols yield much less useful debugging information. For interpreted or managed languages such as Python or Java, GDB is largely unsuitable, since those ecosystems provide their own native debuggers better suited to their runtime models. Debugging heavily optimized release builds can also be frustrating even with symbols present, since the compiler may reorder, inline, or eliminate code in ways that make single-stepping feel disconnected from the original source, which is why many teams keep a debug or minimally optimized build configuration specifically for GDB sessions.
Key Features
- Breakpoints, watchpoints, and step-by-step execution control
- Inspection and modification of variables, memory, and registers at runtime
- Call-stack backtraces for diagnosing crashes and unexpected control flow
- Post-mortem analysis of core dump files after a crash
- Remote debugging support via gdbserver for embedded targets
- Scriptable via Python for custom debugging automation
- Backend for many graphical IDE debuggers including VS Code and CLion
- Support for multiple compiled languages including C, C++, and Fortran