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 :

  1. 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.
  2. 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.
  3. Tracking down the problem. This part is the actual debugging. This may be a difficult step also, if the problem spans across several modules.
  4. 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.

Click here to buy the book.

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:

  • It is free.

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.

Share/Save/Bookmark




Verification Management
Join Verification Management Group


Book of the Month


From Our Press