CS 270 Lab 3: Advanced use of gdb
Part 1: Learn to use ddd
The first part of this lab introduces you to ddd,
a graphical front end to the gdb debugger.
You might like it better than gdb itself.
You will debug the same program you debugged in lab 2, however you will use
ddd to look at the variables buf1 and buf2.
You will not turn in anything for this part of
Download the match.c program to your VM
and run the ddd program on it to debug it. On
your VM you can use the wget program:
to download match.c directly to your VM.
- Compile the program so that it can be debugged (gcc -Wall -g -o match match.c)
- Run ddd on the program (ddd match)
The ddd program requires a connection
to a display. You can
either use your VM console, or if you are using ssh from Unix or a Mac, you could try using
- Use ddd to set break points and examine the
value of buf1 and buf2
at the point that the program calls memcmp().
You can scroll up and down in the
program, and you can set a break point by double-clicking a line of code.
To inspect a variable: just put the mouse over it (for instance, over buf1 in the memcmp() call).
You can also double-clicking the variable; now its value appears in the
upper pane, and it stays up to date as the program continues.
You do not need to fix the bug, and you
do not need to go on to the second bug.
Part 2: Debugging without source code
In the second part you will use gdb to figure out
how to get a program
to run to completion. The challenge in this case is that you will not
be given the source code for the program. Instead, you will simply have to
run the program and figure out what input is required. For this part
of the assignment, you should use the command-line version of gdb and
record your session into the file session.txt that
you then upload to the csportal.
- Start the script command to record your
session (script session.txt)
- Download the binary program a.out (with no
The chmod program makes sure the file is
readable and executable.
chmod a+rx a.out
Genererate assembler language for the program in a file a.s:
objdump -d a.out > a.s
View a.s using vi or
whatever method you are comfortable with.
Look for the main procedure (search for
<main>) and follow the
execution from that point
onward. One quick and simple way to get some feeling for the flow of
control is to find all lines in the file that jump to, or call,
named procedures. Because objdump prints all
procedure names inside
of < and > all you need to do is use grep
to find them. For example, try:
grep '<' a.s
to get a nice listing of all the procedure calls and jump
- Having learned something about the flow of control, you should try to
run the program in the debugger. Use all the gdb
in class to set breakpoints and single-step through the instructions
using the nexti or stepi commands.
You will find this gdb command very helpful to
see the current instruction (in assembler).
- See if you can figure out the secret passphrase that the program expects.
The introduction to gdb from Lab 2 is
Some advanced gdb commands that you may find helpful
can be found in in this file.
Remember to submit a script of your gdb session to