Which C++ debugger should I use? — bigcpp

Q: Which C++ debugger should I use??

Decision guide for choosing between GDB, LLDB, rr, WinDbg, and IDE-integrated debuggers based on platform, use case, and features.

Quick answer

Platform / scenario	Use
Linux — standard debugging	GDB
macOS — standard debugging	LLDB
Windows — MSVC toolchain	Visual Studio Debugger or WinDbg
Intermittent / hard-to-reproduce bugs	rr (Linux, time-travel)
Post-mortem crash analysis (Linux)	GDB with core dump
Cross-platform, terminal-first	LLDB
Kernel / driver debugging	KGDB (Linux), WinDbg (Windows)

Decision flow

What OS are you on?

→ Windows:

Using MSVC? → Visual Studio Debugger (best integration)
Using Clang/GCC? → LLDB or Visual Studio with LLDB backend
Kernel/driver or crash dump analysis? → WinDbg

→ macOS:

LLDB — ships with Xcode, also available as brew install llvm
Alternatively: CLion with its integrated LLDB frontend

→ Linux:

GDB — the default. Available everywhere.
Prefer clang/LLVM toolchain? → LLDB (identical features, slightly different CLI)

Is the bug intermittent or hard to reproduce? → Yes → rr — records execution, replay deterministically, step backward

Are you debugging a production crash from a core dump? → gdb ./binary core — no special tools needed

GDB (GNU Debugger)

Platform: Linux, embedded, cross-platform Best for: General C++ debugging on Linux, core dump analysis, scripting via Python API, remote debugging over gdbserver.

bash

# Build with debug info
g++ -g -O0 -o myapp main.cpp

# Debug
gdb ./myapp
(gdb) break main
(gdb) run
(gdb) next
(gdb) print my_vector   # STL pretty-printing built in
(gdb) backtrace         # call stack

Key strengths:

Mature Python scripting API
gdbserver for remote/embedded debugging
STL pretty-printers for libstdc++
TUI mode (Ctrl+X A) for split source+command view
Excellent core dump analysis

LLDB

Platform: macOS (primary), Linux, Windows Best for: clang/LLVM toolchains, macOS native debugging, modern C++ type display.

bash

# macOS — comes with Xcode CLT
xcode-select --install

# Linux
sudo apt install lldb   # or: lldb-17

# Debug
lldb ./myapp
(lldb) b main          # breakpoint
(lldb) run
(lldb) n               # next
(lldb) p my_vector     # print
(lldb) bt              # backtrace

GDB → LLDB command mapping:

GDB	LLDB	Action
`run`	`run`	Start
`break file.cpp:42`	`b file.cpp:42`	Breakpoint
`print x`	`p x`	Print value
`backtrace`	`bt`	Call stack
`next`	`n`	Step over
`step`	`s`	Step into
`continue`	`c`	Continue
`info locals`	`fr v`	Local variables
`watch x`	`w s v x`	Watchpoint

rr — Time-Travel Debugger

Platform: Linux only (kernel perf events required) Best for: Heisenburg bugs — crashes that vanish under debugger, intermittent race conditions, timing-dependent failures.

bash

# Install
sudo apt install rr   # or: build from source

# Record an execution
rr record ./myapp arg1 arg2

# Replay — fully deterministic, replayable forever
rr replay

# In the replay GDB session:
(rr) reverse-continue       # run backward to previous breakpoint
(rr) reverse-next           # step backward
(rr) reverse-finish         # step out backward
(rr) watch -l memory_addr   # set watchpoint, then reverse-continue to find the write

rr records a complete execution trace (CPU instructions, memory, system calls). Every replay is byte-identical. You can set a breakpoint in the crash, then step backward to find the root cause.

Limitations: ~2-5× overhead during recording. Doesn't support all hardware (AVX-512 problematic). Requires perf_event_paranoid ≤ 1.

Visual Studio Debugger

Platform: Windows (primary) Best for: MSVC-compiled projects, Windows-specific debugging (COM, WinRT, .NET interop).

Features:

Data breakpoints — break when a memory address changes (address watchpoints)
Edit and Continue — modify code while debugging without restarting
Natvis — XML-based pretty-printer for custom types
Parallel Stacks — visualize all threads' call stacks simultaneously
Diagnostic Tools — CPU/memory profiling in the same session

WinDbg

Platform: Windows Best for: Crash dump analysis (.dmp files from production), kernel debugging, driver debugging, post-mortem investigation.

cpp

Godbolt

!analyze -v          # auto-analyze crash dump
k                    # call stack
~*k                  # all threads' call stacks
.frame N             # switch to frame N
dt MyType 0xaddr     # dump type at address

Use WinDbg Preview (Microsoft Store) — modernized UI over the same engine.

IDE-integrated debuggers

IDE	Backend	Notes
VS Code + CodeLLDB	LLDB	Best VS Code C++ debug experience
VS Code + cpptools	GDB or LLDB	Microsoft's extension, decent
CLion	GDB or LLDB	Well-integrated, customizable
Qt Creator	GDB or LLDB	Good for Qt apps
Xcode	LLDB	macOS/iOS native

VS Code launch.json (CodeLLDB)

json

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "lldb",
      "request": "launch",
      "name": "Debug myapp",
      "program": "${workspaceFolder}/build/myapp",
      "args": [],
      "cwd": "${workspaceFolder}",
      "preLaunchTask": "cmake build"
    }
  ]
}

Remote debugging

For embedded or remote machines:

bash

# On target machine
gdbserver :12345 ./myapp

# On host
gdb ./myapp
(gdb) target remote 192.168.1.100:12345
(gdb) continue

LLDB equivalent:

bash

# On target
lldb-server p --server --listen 0.0.0.0:12345

# On host
lldb
(lldb) platform select remote-linux
(lldb) platform connect connect://192.168.1.100:12345
(lldb) target create ./myapp
(lldb) run