GDB for Anyone but a Dummy


gdb is a nearly universal command-line debugger for the GCC and G++ compilers. gdb works on the command line. There are fancier debuggers, but none is more universal. If you learn only one debugger, gdb should be the one. GDB is a little strange to get used to, but it is consistent and powerful, and it provides you a marvelous tool for understanding what's happening in the computer.

Getting Started

Debuggers are not used to find syntax errors. Normally, the compilation process will 'helpfully' point out your syntax problems. Use gdb or another debugger when your program compiles but does not work properly. Debuggers are mainly used to check for logic errors.

gdb only works on compiled code, so you will need to compile your program before running GDB on it. However, a normal compilation does not retain variable and function names. If you intend to debug your program, you'll need to use a variation of the compilation command to add a 'symbol table,' which adds a list of all the variable names and function names to the executable. Use one of these commands:

        gcc -g foo.c


        g++ -g foo.c

If you do not include the -g directive, you will be able to use gdb, but it will be much more difficult, because you will not have access to variable or function names.

As an example, consider the following very simple C program:


void doLoop(){
  int i = 0;
  for (i = 0; i < 10; i++){
    printf("%d ", i);
  } // end for
} // end doLoop

int main(){
  char name[10] = "George";
  printf("Hi, %s, I'm in main \n", name);

Once you have an appropriately compiled version of the program in question, start gdb on the executable. In most unix systems, it will be something like this:

gdb a.out

You'll see some slightly scary output, but the program should load.

GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /home/aharris/public_html/240/a.out...done.

Testing your program

Now that you're in the code, you can do a number of things: list the code, set a breakpoint, view your variables, change a value, or run in slow-motion.

list 10 lines of code. If you type list (or l) again, the debugger will print the next ten lines. If you specify a line number, gdb will print the ten lines centered on that line. l 10 lists lines 5 - 14
Runs the program from the current spot. If you have not set a break- point, run works just like running the program from the normal console.
Sets a breakpoint. Use a line number or a filename to specify where the debugger will stop. For example, break 5 stops right before running line 5, and break main stops right before running main. Normally you'll set a break point before you run the code, so code will go normal speed until you get to the breakpoint
Steps through the next line of code. Prints the following line. The line you see is the one that's about to be executed. As soon as the line is run, execution pauses again so you can check on the status of your variables.
Similar to step, except when the next line is a function call. If the next line is a call to a function, the entire function is considered a single line. Use this when the algorithm you're testing calls a function you trust, so you don't have to deal with all the details of the function.
Allows you to print the content of any variable. The variable is returned with a temporary name ($1 through $n) which you can use in subsequent print statements
Allows you to look at the stack. This can be helpful when you're dealing with scope and memory issues.
This command allows you to alter the value of a variable at any time, as long as that variable is currently in scope. EG set x = 5