gdb (and ddd) Command Reference

ddd is a GUI written atop gdb, but sometimes less tedious to use. gdb is a mostly command line-oriented debugger that is more stable than ddd.

For tutorials, see


Movement commands...
where tell me where I am
advance where go to where
continue go on from current breakpoint
finish perform a magic return from function?
jump where where
next step to next statement
nexti step to next assembly instruction
run <args>
set args args set up argv[]
show args show arguments
start b main; step to main
step where single-step to where

Breakpoints...
break where set a breakpoint at where
where can be the name of a function
where can be filename:line-number, e.g: “main.c:236”
tbreak where set a temporary breakpoint at where
watch variable set a watchpoint on variable (break-write)
info break numbered list of breakpoints
delete n delete breakpoint n
clear where clear the breakpoint at where
condition n condition make breakpoint n conditional

Examining data...
print variable show contents of variable
print /x $pc shows eip in hex*
x/10x dogfood dumps first 10 long words of dogfood in hex*
x/10d dogfood dumps first 10 long words of dogfood in decimal*
x/10c dogfood dumps first 10 long words of dogfood as characters*
ptype struct_var dumps out fields of struct_var
display variable watch variable change while stepping
info display numbered list of variable displays
delete display n stop watching n
set print object show structure pointed to rather than base address
set print elements n show n elements (characters in string, etc.); for unlimited, use 0
set print pretty on turn on newlines and indentation in displaying structures

Source code...
list n show source code at line n in current file
list function show source code for known function
directory dirname insert dirname in front of existing search path so that a function’s code can be displayed.
show directories display existing search path (list of directories)
list - show lines of context prior to current location
set listsize n show n lines of context around current location

Miscellaneous...
backtrace perform a stack crawl
up | down move up or down one activation in the call-stack
return perform a magic return from function
call func( args ) execute func with args
shell command execute command in owner’s shell outside of gdb
set follow-fork-mode in stepping or continuing, follow fork calls down through child process (and abandon parent) or through parent (and not child) by specifying “child” or “parent” (parent is the default)
At least in ddd, this value is sticky and stepping mysteriously does the same thing at the next debugging session unless reset.

Various notes...

ddd has peculiarities. It grows unstable sometimes, especially in the command line window where beyond a point, you will no longer be able to enter gdb commands. I haven’t experimented carefully for this, but my impression is that at least a restart is needed, often a reboot. (Yeah, I’m having a hard time with that one too, but simply restarting doesn’t always fix the problem.)

As near as I can tell, there is no documentation or support for ddd. There are a few useful tutorials on gdb including on how to use it to debug curses programs. I have tried this, but even following the tutorials closely, debugging curses programs sucks rocks in gdb. For most problems, printf works much better.

On the surface, ddd comes close to being a useful source-level debugger. It’s main virtue is to remove console noise and confusion from gdb in the way source code and watched variables are display. It is also simpler and more visually oriented to use in setting simple breakpoints.

ddd also suffers from less-than-reliable source code listing, something it shares with gdb.

To wit: upon arriving at a breakpoint, it doesn’t always know where it is and like the sonar analysis software on FBM Dallas of Tom Clancy fame, almost consistently “runs home to mama” in that it will list your main function source code instead. But, if you step to the next statement in the code using n, this clears itself. I usually set my breakpoints one instruction ahead if using s or n will take me past where I wanted to be.

gdb is more stable and more useful than ddd when it comes to tracking down failure points for which the program needs to be stopped, restarted and break-pointed in a slowly incrementing point as you edge up on the problem. I find it better when attempting to run, find things bad, record where, start over and run again, but this might be one narrow type of problem. I haven’t had much experience using gdb and my days of dbx go back nearly 20 years.

Use .gdbinit in local directory to implement preparatory commands.

Use TAB to complete command.

Press RETURN to repeat last command.

Other format specifiers include: decimal, unsigned, octal, two (binary), address, character (prints as both character and its decimal value), and floating point.


ddd madness...

“Can’t open display”

When ddd is launched, sometimes the environment isn’t cooperative. There are things to do to solve this and I don’t grok the whole situation well enough to speak intelligently about it, so do these things: 

	export DISPLAY=:0.0

	User_Alias X_USERS = russ[, someone-else, etc.]
	.
	.
	.
	Defaults:X_USERS env_keep += DISPLAY
	Defaults:X_USERS env_keep += XAUTHORITY

	if [ -f ${HOME}/.bashrc ]; then
	  . ${HOME}/.bashrc
	fi

xhost

Also, xhost, used to add or delete host or user names to the list of those allowed to make connections to the X server, is meaningful: the user running must be granted this privilege: 

	russ@taliesin:~> xhost +russ
	taliesin:~> xhost +localhost