Lab 4 — Using the Debugger & Passing Arrays to Functions

Wednesday, November 20, 2008

Objectives

·        To learn to use a debugger

·        To gain experience with arrays and passing them to functions

Note: don’t worry if you can’t finish the entire lab exercise. Use turnin (see the last step) to turn in as much as you’ve completed before you leave the lab. Make sure you finish the rest of the lab on your own time.

What you should do...

1.      Sign the attendance sheet.

2.      Using emacs or your favorite editor, open a new file named lab4.c. Write a program that first asks the user to enter an integer in the range

0 < n <= 20

Next the program creates an array of double with n elements in it, and finally it reads in n floating point numbers and saves them in the array.

3.      Compile and run your program. Your program doesn’t produce any output, so it’s hard to tell if it works correctly! Use a debugger to convince yourself that the program works. The program gdb (gnu debugger) lets you run your program in a controlled way, one command at a time, so you can see exactly what’s going on. Here are some useful gdb commands:–.

help                    help

list                    display ten more lines

list <line number>      display ten lines centered around <line number>

list -                  display ten lines previous to the lines just printed

print <variable name>   print the value of a variable

break <function name>   set a breakpoint at the start of a function

break <line number>     set a breakpoint at the specified line

cont                    continue execution after a breakpoint

clear <function name>   remove all breakpoints from function

run                     run program with optional arguments

step                    resume execution for just a single statement

quit                    exit the debugger

backtrace               shows layers of functions you are into

A breakpoint is just what the name implies — a point at which you suspend of the currently-executing program and enter the debugger for the purpose of looking around. You can then check out the state of your variables to make sure they contain the values they should contain. If you reach a breakpoint and you find something amiss, you know that there is a bug in your program in one of the instructions that executed prior to the breakpoint. If, on the other hand, everything looks OK, you can narrow down your search for bugs in the instructions that execute after the breakpoint.

Loops are usually good places to put breakpoints; start by placing a breakpoint immediately before a loop and immediately after. If it looks like there may be a problem inside a loop, place a breakpoint within the loop to allow you to at a key place during each iteration so that you can look at the loop control and other variables.

Likewise, the start of a function is often a good place to place a breakpoint so that you can see the argument values when the function is called.

4.      When you want to use a debugger, you must tell the compiler first, so that it can include information about line numbers, etc. Do this by compiling with the –g switch; i.e.,

     gcc –Wall –g lab4.c

After the program has been compiled, start running it by typing

     gdb a.out                       

This will start the debugger, load your program, and begin with the debugger prompt:–

     (gdb)

5.      Use the following commands to set breakpoints and check the values of your variables: list (to get the line numbers), break <linenumber> (to set a breakpoint), run (to start the program), print <variable name> (to check the current value of a variable), cont (to run up to the next breakpoint). Debug your program until you are comfortable that it runs correctly.

6.      Next, add a function that returns the largest number stored in the array. The function should accept two arguments —  the array itself and the size of the array. Compile your program, and then use gdb to verify that it works (demonstrate your program running under gdb for the TA). If you are running out of time, go to the last step. If you have at least 15 minutes left, proceed to the next step.

7.      Now write a second version of the same function, but this time write the function recursively. What is the ‘size’ of this problem? How can you reduce the size with each successive recursive call? What would the base case be for this function, and what would it return? Compile your program. Use gdb to verify that your program works.

8.      Turn in your file using the turnin program. The Unix command you should use to submit your files is

/cs/bin/turnin submit cs2301 lab4 lab4.c

Refer to this lab page as you work on the remaining assignments this term. Today’s program was fairly simple and could easily have been debugged by just looking at it. As your programs become more complicated and harder to debug, you will appreciate the value of a tool like gdb. If ever you have to write real-life programs in C, a debugger and debugging skills are absolute necessities. Type man gdb at the Unix prompt if you would like more information about gdb.

See you next week!