gdb

Debug an executable

$ gdb [executable]

$ gdb [[-p|--pid]] [procID]

$ gdb [[-c|--core]] [core] [executable]

$ gdb [[-ex|--eval-command]] "[commands]" [executable]

$ gdb --args [executable] [argument1] [argument2]

$ gdb [[-c|--core]] [core] [executable] -iex 'set debuginfod enabled on' -iex 'set pagination off' -ex bt

gdb [options] [executable_file [core_file | process_id]]

-q, --quiet, --silent
    Do not print the introductory and copyright messages.

-ex COMMAND, --command=COMMAND
    Execute the specified GDB command upon startup.

-s FILE, --symbols=FILE
    Read symbol table from FILE.

-c FILE, --core=FILE
    Use FILE as a core dump to analyze.

-p PID, --pid=PID
    Attach GDB to the running process with the given PID.

-b BAUDRATE, --baud=BAUDRATE
    Set the serial device baud rate for remote debugging.

-tui
    Start GDB with the Text User Interface enabled, showing source code, assembly, and registers.

executable_file
    The program to be debugged. GDB loads its symbols and prepares to run it.

core_file
    A core dump file generated by a crashed program. GDB analyzes its state.

process_id
    The ID of a running process to attach to for live debugging.

The gdb command, short for GNU Debugger, is a powerful, open-source debugger for various programming languages, most notably C and C++. It allows you to examine what is going on inside a program while it executes or what a program was doing at the moment it crashed.

Key capabilities include:

• Setting breakpoints to pause execution at specific points.
• Stepping through code line by line.
• Inspecting and modifying variables and memory.
• Analyzing call stacks to understand program flow.
• Debugging core dumps to investigate crashes post-mortem.
• Attaching to running processes.
• Debugging remote targets over a network.

Debugging with gdb is most effective when the target program is compiled with debug symbols (e.g., using -g flag with GCC). Without symbols, debugging is limited to assembly level. The learning curve can be steep for beginners, as it primarily operates via a command-line interface. Debugging a running process introduces overhead and can slightly alter its real-time behavior. Complex multi-threaded or multi-process applications can be challenging to debug effectively with GDB alone.

• Post-mortem Debugging: Analyzing core dump files to determine the cause of a program crash.
• Live Process Debugging: Attaching to a running process to inspect its state or debug issues in real-time without restarting.
• Step-by-Step Execution: Understanding program flow by executing code line by line and observing changes in variables and memory.
• Remote Debugging: Debugging programs running on embedded systems or different machines via a network connection (often using gdbserver).

• Command-Line Interface (CLI): The default interactive mode, where users type GDB commands.
• Text User Interface (TUI): Activated with -tui, it provides a curses-based interface showing source code, registers, and assembly alongside the command line.
• Batch Mode: Executing GDB commands from a script or file for automated debugging tasks.
• Integration with IDEs: Many Integrated Development Environments (IDEs) like VS Code, Eclipse, and CLion use GDB as their backend debugger, providing a graphical frontend.

Developed by Richard Stallman in 1986 as part of the GNU Project, gdb was initially designed to debug programs written in C. Over the years, its capabilities have expanded to support C++, Fortran, Ada, Go, Rust, and other languages. It quickly became and remains a cornerstone tool for open-source software development and system-level debugging on Unix-like operating systems. Its active development continues, ensuring its relevance in modern programming environments.

strace(1), ltrace(1), valgrind(1), objdump(1), nm(1), ldd(1), gdbserver(1)