Goals

• Learn how to debug .c files using GDB
• Set breakpoints
• Step through program to find and solve bugs
• Create a "fixedFoo.c" file, compile and run to make sure it works

Needs

• foo.c
• foo

NOTE: Once downloaded, these files (mainly the foo executable) might have the execute permissions not set. YOU MUST SET THESE. It can be done using chmod 700 foo.

Tutorial

GDB (GNU Project Debugger), "allows you to see what is going on 'inside' another program while it executes -- or what another program was doing the moment it crashed." GDB can:

• Start your program, specifying anything that might affect its behavior.
• Make your program stop on specified conditions.
• Examine what has happened when your program has stopped.
• Change things in your program so that you can experiment with correcting the effects of one bug and go on to learn about another.

Running GDB is easy; just type
gdb program_to_debug and you're up and running. NOTE: The program_to_debug executable MUST have been compiled with the -g flag set in gcc. This allows for the creation of the debug symbols needed by GDB.

There are 5 basic commands you will need to know when using GDB.

1. b - sets a 'b'reakpoint, to pause execution, at a certain location. USAGE:
   
   (gdb) b line_number
   or
   (gdb) b function_name
   
   You can also optionally define the filename to set the breakpoint in:
   (gdb) b [file_name]:line_number
   
2. r - 'r'uns the program up until a breakpoint is found. If no breakpoints exist, the entire program is run like normal.
3. n - once a breakpoint is hit and GDB suspends execution, 'n'ext advances execution exactly one line. In Java debugging, this is equivalent to "step over".
4. s - a lot like 'n', 's'tep advances execution one line, but goes into a method if the next line is a part of another subroutine (i.e. another method). In Java debugging, this is equivalent to "step into".
5. bt - 'b'ack't'race shows where you are in the stack. Use it to display the stack from for the method you're suspended in.
6. p - 'p'rints the value of a variable. USAGE:
   (gdb) p variable_to_examine
7. l - 'l'ists 10 lines of source code surrounding the current suspended line.
8. c - 'c'ontinues execution.
9. quit - quits GDB.

//TODO

You are given a foo.c file and a compiled (with -g flag) foo executable. The program was created to accept a %d input from the user and then print out the factorial of that input. Unfortunately, there is a bug(s) involved. Your job is to fix the bug by debugging within GDB only. You are not allowed to recompile foo.c.

Turn in a sheet of paper with your name on it describing the bug and how it was fixed. Make sure this is turned in before you leave lab; it will be how you will get credit for being here.

Hints

• The p command can print the value of any expression (i.e. you can have it print an assignment so that it could actually change the variable) For ex:
  (gdb) p variable_to_change=6
  will set variable_to_change to 6.
• The info command allows you to get information on certain things. Try (gdb) info breakpoints.
• GDB allows you to use the TAB key to fill in using type ahead.
• The help command will give you some.
• The save breakpoints [filename] command will save the current breakpoints into a file. You can load that file at the beginning of GDB with the source [filename] command. ANOTHER WAY TO DO THIS is to create a .gdbinit file in the same directory as the executable you are debugging. This file can contain any gdb commands (as long as they are on their own lines) and each will be run exactly once by GDB on startup. *This can really come in handy.*