Previous Section: Introduction to debugging
Next Section: Make your program gdb friendly
gdb - The Tool of the Trade
As they say, 'A handyman is as good as his tools'. We need a proper
tool to help us debugging. In this part, we
pick up one.
How do I debug my code ?
There are four steps in debugging a program. They are, in order :
-
Finding out that the bug exists. Ideally speaking, this is what your verification
team should do before your product goes to the market. If it can not, do
not worry, your customers will find the bug.
-
Reproducing a bug. Once your verification team (or your customer) finds
out a bug, they will not tell you what exactly the problem is - they
will only give you hints regarding its symptoms. So, you will have
to reproduce the bug in your test environment. As you understand by now,
this may be the hardest part depending on the nature of the bug.
-
Tracking down the problem. This part is the actual debugging. This may be a
difficult step also, if the problem spans across several modules.
-
Fixing the bug. If you have done Steps 2 and 3 above correctly, this has
to be the easiest part.
In this article, we will concentrate on Step 3 only.
The golden rule of debugging is: always attack bugs one at a time. There
may be several bugs in your program, but each time when your program crashes,
it is always because of one bug (this bug may, of course, be generated
by multiple mistakes). The only way to eliminate all bugs from your program
is to remove them one by one.
Source level debugging
There are several ways to track down a bug. But experiences have shown that
the most convenient way of debugging a program is to determine where exactly
the program has gone wrong (i.e. the line where it stopped working and crashed)
and start backtracking from that point. Here 'backtracking' means examining
the values of related variables in or around the suspicious line, stopping
a few lines before that and then to run one line of source code at a time
to check what exactly is happening until we determine the source of the problem.
This methodology is known as Source Level
Debugging and tools which help you to do
this are known as Source Level Debugger.There are
other types of debuggers, such as, assembly level debuggers, but they are
not as useful.
Our choice: gdb
There are several source level debuggers. Some are commercial products. Many
are freewares. If you are using a UNIX-like system, your system should
have a utility program called dbx. If you are using
a Windows-based system, your language developer's package (such as,
Visual C++ etc.) has a source level debugger.
In this article, for the purpose of discussion, I shall use another source
level debugging tool, called gdb. It is a GNU utility.
There are several reasons why I have chosen this one over others. Some of
them are:
-
It is available across many platforms.
-
It works independent of what compiler you are using. You do not have to use
gcc to use gdb, but I would recommend that.
-
It has all the features that we need.
and the best reason is:
Where can I find gdb to download ?
gdb source can be downloded from
here. It can be configured before
compilation to use in different systems. gcc source for UNIX systems is available
here and for DOS/Windows,
here. A graphical user interface
to gdb, called
xxgdb for
X-windows based systems is also availbale.
Previous Section: Introduction to debugging.
Next Section: Make your program gdb friendly.