I cooked this up for one of my clients just now,
and I wanted to put it in a public place. Feel
free to comment over on my regular weblog.
link to this info
To get gdb to start a program do either:
$ gdb binary
(gdb) file binary
You'll need to start the program now, with
any arguments if it takes them:
(gdb) run [arguments]
To run gdb on a core file gives you roughly the same
stuff as getting the program to crash while the
debugger is running. Run:
$ gdb binary corefile
To use gdb to attach to a running process,
find the pid of the process you want to debug.
$ gdb binary pid
$ gdb binary
(gdb) attach pid
This stops your process, in order to continue it
Otherwise you may want to look at a stack trace
of where we are right now, and maybe some of the
values of variables.
(gdb) where OR (gdb) bt
This numbers the stack frame as well, and by default
you are at the deepest level.
(gdb) print myvariable
This works on values within the current scope - by
default they are in the deepest frame on the stack,
but you can change frame by:
(gdb) frame 10
Breakpoints and Stepping:
You can at this point continue the program to get
where you want it to go, or you can set up some
breakpoints to make the program stop at a specific
line. (You can also make the program stop with ctrl-c)
(gdb) break foo.c:400
You can also step line by line from your current
location. 'next' executes the next line, and 'step'
executes the next line but steps into the next line
if it is a function call. Both take numeric arguments
so you can say 'next 10' and it will try to execute
the next ten lines.
(gdb) next 2
When a program crashes in the debugger, it will stop
in gdb (generally - given we are not set up to operate
within a subprocess - which you can look up in the
online docs) and you can do any of these commands
except executing further.
Anything else and specifics on these commands you can
look up by doing 'help' at the gdb prompt