Using gdb, the GNU C/C++ debugger
Programming in C and C++ can be a challenge. Because of the power and
flexibility of both languages, it is easy to make hard-to-find errors.
There are few times more frustrating than when a program compiles
successfully, but produces the cryptic error
Segmentation fault or Bus error.
This is when GDB, the GNU Debugger, comes in handy. This Quick Reference
Guide hopes to get you started towards using GDB to debug programs
successfully.
-
First, you need to compile your program with debugging information. This
way, GDB knows the names of your variables and what each line of your
program says. To compile a C or C++ program to be used with GDB named
program.c or program.cc,
for instance, use one of these commands:
% gcc -ggdb program.c (This compiles a C program with GDB debugging information.)
% cc -g program.c (The standard C compiler has only a generic debugging option, which also works with GDB.)
% g++ -ggdb program.cc (This compiles a C++ program with GDB debugging information.)
-
Now you are ready to use GDB. To start the debugger, type:
% gdb
This command places you at GDB's prompt. Here, load the file you want
to debug with the file command:
(gdb) file a.out (a.out is the name of your compiled file)
From here, you have many options. Most often, you want to trace your
program, watching each line execute. To start tracing, set a
breakpoint at the first executing line, usually
main(),
by typing:
(gdb) break line_no (line_no is the line on which you want the program to stop.)
If you don't know which line is which, type
list
to see your program, complete with line numbers. With the breakpoint set,
you are ready to start your program by typing
run.
With the
run
command, you can pass arguments to your program or redirect
input to it as if you were running it from the shell.
-
At this point, hopefully your program has come to a screeching halt
at the breakpoint you set. Now you can type
step or n
to continue, one line at a time. Just typing
Return
will repeat the previous command, so you can use this method to
quickly step through the program If your program enters a
for
loop and you grow weary of pressing
Return
you can use the
until
command, which continues "until" your program exits the loop.
When you reach a function, you can use s to step into it.
The impatient can use call function to call a given function
immediately.
Finally, if the program calls a library function (like
printf()
or
cout
) you can get GDB to continue through the library function and stop
again when your program regains control by using
finish.
-
With what you know so far, you could probably find an infinite loop in your
program, or perhaps isolate the location of a segmentation fault.
However, to get even more out of GDB, you can use it to examine the
values of variables in your program as it runs. To do this you use the
print
and
display
commands.
Print
lets you look at a variable's contents once.
If you want to trace the value of
foo
and have it displayed continuously, you can use the
display
command. These commands are used like this:
(gdb) print foo (Print the value of foo one time.)
(gdb) display foo (Display it after each step.)
One thing to note about
display
commands is that they are local. That is, they only apply to the function
in which they are given. If you
display
a variable in a function called by
main(),
when control returns to
main()
that variable will disappear from view. Once your program re-enters
the subroutine, the
display
command will again take effect.
Another information gathering tool is the info command.
For example:
(gdb) info locals (Prints all local variables.)
(gdb) info args (Print current values of this function's
arguments.)
In addition, the command whatis can be used to display the type
of a given input.
One last command that you will find helpful is
quit.
While quitting, if your program has not exited, GDB will ask you if
it's OK to kill your program for you. Answer yes. This won't hurt
anything, and is the only way to exit at that point.
-
If the previous debugging methods still aren't helping, gdb has a few
big guns that may help. Thread management can be done by using
info threads to list the current threads then typing:
(gdb) thread n
to go to thread number n.
Stack management is also an option. bt displays the current stack
and then you can use:
(gdb) frame n
to go to stack frame n.
If all else fails, the command x allows you to do many types of
memory dumps. Use help x to get more details.
Notes:
You may also use the -g flag on gcc or
g++, but this is not as useful to GDB (and consequently
its user) as the -ggdb flag which is available on both.
Make sure that you have access to the source files of your program if
you wish to use them to debug. This is most easily accomplished by
running gdb in the same directory as the source files and executable
are in.
Especially if the file you want to debug is rather large, you may want
to skip using breakpoints to step through to an error and make a
preliminary diagnosis of your program by using run right after
loading to get to the source of your problem and examine how the
program crashes. This may also tell you a good place to set a
breakpoint.
It is worth noting that it is possible to use a grapical version of
gdb if the command line version is too obtuse. Simply typing
%ddd will load the gdb graphical overlay.
It is possible to use all the commands mentioned earlier through a
command prompt at the bottom screen, but all features can be accessed
through the menus as well.
If you need more help while in GDB, you can get help on GDB commands
by typing help at the (gdb) prompt. Another
excellent place to go for help is to GNU's Info system. Enter info
gdb at your prompt to use it. Also, Cygnus Support has made
available a handy
Postscript GDB reference card, which you can print double-sided on
a single sheet using the printer psdup. They also have available
online an HTML version of the
GNU Info file on GDB, which is probably much easier to
navigate. The manual page on GDB provides more information, especially
on the command-line options available. Enter man gdb on turing
to view it. Finally, asking the consultant on duty or sending mail to
consult@turing is a good way to get help if you're still
puzzled. Good luck getting the bugs out!
Copyright (c) HMC Computer Science Department.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with the no Invariant Sections, with no
Front-Cover Texts, and with no Back-Cover Texts.
A copy of the license is included in the section entitled ``GNU Free Documentation License.''
|
