Show Menu
Cheatography

Best GDB Cheat Sheet (DRAFT) by

A well organized GDB cheat sheet, with the most important (i.e. commonly used) stuff.

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Launching

gdb -p <pi­d>
attach gdb to an existing process
gdb --args <ex­e_f­ile> [arg1] [arg2] ...
make gdb launch an executable file, passing some arguments to the executable file
gdb --batch –x <co­mma­nd_­fil­e> --args <ex­e_f­ile> [arg1] [arg2] …
make gdb launch an executable file (passing some arguments to it), then have gdb execute gdb commands from a "­command file"

Execution Control

continue
continue execution of the process until a breakpoint (or catchp­oint) is hit
next
continue execution of the process until the next line of code
step
continue the execution of the process until the first instru­ction of the next function (aka "step into")
finish
continue execution of the process until the current function returns
"Ctr + c" (while the gdb terminal window is focused) to break the process right where it is at.

Viewing Source

layout next
enable tui mode (top part of terminal will show source location of where you're currently broken)
tui disable
disable tui mode
list
print next 10 lines of code
list -
print previous 10 lines of code
list <fi­le>­:<f­unc­tio­n>
print 10 lines of code around a specific function in a file

Viewing Variables

print <va­ria­ble­_na­me>
print a variable (must be in scope of course)
backtrace
print callstack
backtrace -n
print top n frames of callstack (n can be any number)
frame n
select frame number n (nth frame from the top). Frame is another word for a particular function in a callstack.
up
select the next frame up
down
select the next frame down
info args
print the arguments passed to the selected frame (function)
info locals
print the local variables defined in the selected frame

Breakp­oints

info breakp­oints
print inform­ation about breakp­oin­ts/­cat­chp­oints that you've placed
break <fu­nct­ion­_na­me>
place a breakpoint on a particular function. Write the full name of the function, as you would specify it in C++ (e.g. ClassN­ame­::f­unc­tio­n_n­ame). If you have multiple functions with the same name, include argument types to disamb­iguate.
break <fi­le>­:<l­ine­_nu­mbe­r>
place a breakpoint on a particular line of a particular file
delete <br­eak­poi­nt_­num­ber>
delete (remove) a particular breakp­oint. "info breakp­oin­ts" will show you the breakpoint numbers for all the breakp­oints that you've placed.
disable <br­eak­poi­nt_­num­ber>
disable a particular breakp­oint. A disabled breakpoint still shows up when you do "info breakp­oin­ts", but it won't be hit until you enable it.
enable <br­eak­poi­nt_­num­ber>
enable a particular breakpoint
break <fu­nct­ion> if <co­ndi­tio­n>
place a condit­ional breakpoint (i.e. only break if a certain condition is true). The condition is any valid C++ expression that evaluates to true or false. You can use conven­ience variables as well as any variables in scope for the condition.
condition <br­eak­poi­nt_­num­ber> [condi­tion]
define a condition for an already placed breakp­oint. If you leave out the [condi­tion], then you are saying to make the breakpoint uncond­itional (i.e. remove any existing condit­ions, if there are any).
commands <br­eak­poi­nt_­num­ber>
specify gdb commands that should automa­tically run whenever the breakpoint is hit. After you run this command, typing a bunch of newline seperated commands that should be executed when the breakpoint is hit. After you are done entering your commands, type "­end­".