Lab 4: GDB (and Functions)

This lab introduces the use of the GNU Debugger. Very generally, a debugger is a program that is designed
to help find and fix (debug) errors in a program. A few of the most useful functions of most debuggers
include:
• Stepping - the ability to step through the execution of a program one line at a time. This makes it
easier to see exactly what the program is doing at each line.
• Printing variables - the ability to print the value of any variable at any point in the program at any
time. This makes it easier to identify when a variable receives an unexpected value.
• Displaying memory - the ability to display the contents of memory. Programs don’t just store variable
values in memory. It can sometimes be useful to look at all of the memory a program is using.

• Break and/or watch points - the ability to stop a program at a particular location or when a specific
condition is met. This makes it easier to observe the execution at a particular point in the program or
under particular conditions.
To use the Gnu debugger the program should be compiled with the debugger option on:
prompt> g++ -g program.cpp
Then begin running the debugger with the program:
prompt> gdb a.out
At this point the debugger will start and the screen will display a block of text followed by the gdb prompt,
something like:
(gdb)
At this point there are a number of basic gdb commands that can be used:
• run a.out (where a.out is the program name) - This runs the program.
• break N (where N is a line number) - This will cause gdb to pause in running the program when it
reaches line N .

• break function name (where f unctionname is the name of a function) - This will cause gdb to
pause in running the program when it reaches the function with the given name.
• step - If gdb has paused the program (for example because the break command was used), this will
cause the next line in the program to be executed.
• print variable (where variable is the name of a variable) - This will print the value of the named
variable, or will give an error message if no variable with that name is currently in scope.
• continue - This causes the program to continue running normally, until the program ends or another
breakpoint is reached.

1 Lab Exercise
Enter the program listed below:

1
1] /* Name
2] * Section \#
3] * Lab 4
4] * Date
5] */

6] #include<iostream>
7] using namespace std;

8] int func(int);
9] const int X = 5;

10] int main(){

11] cout << "Program is starting.\n";
12] int result;
13] int X = 10;
14] cout << "In the middle of the program.\n";
15] result = func(X);
16] cout << "The result is " << result << ".\n";
17] }

18] int func(int y){

19] int answer;
20] cout << "In the function.\n";
20] answer = y;
21] answer += X;
22] int X = 20;
23] cout << "In the middle of the function.\n";
24] answer += X;
25] cout << "The function is exiting.\n";
26] return answer;
27] }

1.1 Problem 1: Hand Simulation

A hand-simulation is when you run/debug a program by playing the role of the computer. You do this by
tracing through the program and simulating what the program will do. One useful approach is to move a
thumbtack or penny or other small object through a printout of the code. You should draw boxes for each
variable, to simulate the bits of memory that hold that variable’s value. A large part of hand-simulation
is updating the contents of these boxes whenever an assignment or input statement updates the value of a
variable.
It often helps to give each variable an entire “column” and update its values by crossing out its old
value and writing its new value below the old value. The other large part of hand-simulation is to write
down in a separate area what output the program’s output statements would generate when they execute.

2
When functions are called, new boxes are created for each local variable (including parameters), and when
a function returns, local variables’ boxes are destroyed.
For example, sample set of columns for hand simulating the lab program would look like:
X result answer y Output

Hand simulate the program. Using the first table at the back of the lab record the values of the variables
X, result, answer, and y at the following lines in the program: 11, 14, 16, 20, 23, 25. For some lines, some
variables will not be defined, record that information instead of the variable’s value.

1.2 Problem 2
Using gdb and the break, step, and print variable commands record the values of the variables X, result,
answer, and y at the following lines in the program: 11, 14, 16, 20, 23, 25, in the second table in the back
of the lab. (This could be done by putting lots of extra cout statements in the program, but for this lab we
will use gdb instead.) For some of these lines you will get an error because the variable doesn’t exist within
the scope of that line.
Do not go back and change the values in your first table.

1.3 Problem 3
Answer the following questions:

1. On line 14, what is the value of result and where did it come from? If you run the program several
times, does the value of result at line 14 ever change?
2. What are the values printed for X on lines 14 and 20? Why are the printed values of X different?
3. Compare the values in Table your first and second tables? We they different at any of the lines? If so
explain the mistake you made during the hand simulation.

Turn-in:
Turn in both tables and the answers to the three questions, you don’t need to turn in the
program or sample output.

3
 Name:

Table 1: Fill in the results of your hand simulation

Line Number X result answer y

11

14

16

20

23

25

Table 2: Fill in the results from using gdb

Line Number X result answer y

11

14

16

20

23

25