What it does
gdb is the GNU Debugger. It allows you to run programs under controlled execution, pause them, inspect variables, step through code, examine memory, and analyze crashes (core dumps).
How it works (mechanical)
gdb uses the ptrace interface to control a target process.
It reads debugging symbols (if present) to map machine instructions
back to source code. Without symbols, you can still debug at the assembly level.
- Best results when compiled with
-g - Can attach to running processes
- Can analyze core dumps without re-running the program
10 Practical Examples
# 1) Compile with debug symbols gcc -g program.c -o program
# 2) Start debugging gdb ./program
# 3) Run inside gdb (gdb) run
# 4) Set a breakpoint at a function (gdb) break main
# 5) Step through code line-by-line (gdb) step (gdb) next
# 6) Print variable value (gdb) print myvar
# 7) View backtrace after crash (gdb) bt
# 8) Attach to running process sudo gdb -p 12345
# 9) Analyze a core dump gdb ./program core
# 10) Disassemble a function (gdb) disassemble main
Notes & Gotchas
- No symbols: debugging is harder without
-g. - Optimized builds:
-O2/-O3can inline or reorder code. - Permissions: attaching to processes may require root.
- Core dumps: enable with
ulimit -c unlimited. - ASLR: memory addresses vary unless disabled.
Historical Context
gdb has been a foundational Linux/Unix debugger since the GNU project era. It evolved alongside GCC and glibc, becoming the standard debugger for C, C++, and later many other languages.
Modern Equivalent / Related Tools
- lldb — LLVM debugger
- strace — syscall tracing
- ltrace — library call tracing
- perf — performance profiling
- bpftrace — modern dynamic tracing