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 the lab.

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:
      wget http://www.cs.uky.edu/~raphael/courses/CS270/laboratory2/match.c
to download match.c directly to your VM.

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 mysession.txt that you then upload to the csportal.
  1. Start the script command to record your session (script mysession.txt)
  2. Download the binary program a.out (with no source code):
          wget http://www.cs.uky.edu/~raphael/courses/CS270/laboratory3/a.out
    chmod a+rx a.out
    The chmod program makes sure the file is readable and executable.
  3. Genererate assembler language for the program in a file a.s:
          objdump -d a.out > a.s
  4. 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 instructions.
  5. Having learned something about the flow of control, you should try to run the program in the debugger. Use all the gdb commands discussed in class to set breakpoints and single-step through the instructions using the nexti or stepi commands.
          gdb a.out
    You will find this gdb command very helpful to see the current instruction (in assembler).
          display/i $pc
  6. See if you can figure out the secret passphrase that the program expects. Some hints:
  7. The introduction to gdb from Lab 2 is here (PDF). Some advanced gdb commands that you may find helpful can be found in in this file.
  8. Remember to submit a script of your gdb session to the csportal.