Yesterday's lecture described how the stack frame is used to keep track of function invocations. Today, we get to investigate this with the gdb debugger, and get started on Project 3.
Download and untar lab9.tar.gz. This will make a lab9 directory that has examples of all of the programs the Professor has been using to describe X86. Specifically, prog.c is an example of a main function that calls myfunc. In prog.c, the myfunc function does a couple of sequential C statements, and returns a value. (In the other .c files, myfunc includes control structures. For instance, in progIf.c, myfunc has an if/then/else statement.)
The Makefile in the lab9 directory supports three different targets that use prog.c as input. The first is prog.s, which is the result of running the compiler to create the x86 assembler translation from prog.c, and then saves that x86 assembler in a man-readable file. The target progG creates an executable from prog.c called progG with debug turned on (like we are used to.) The target prog creates an executable from prog.c called prog with no debug (like our bomb.)
Build progG and prog in the lab9 directory, and then run GDB on the result. Try out the x86 oriented GDB commands we learned about in the x86 gdb lecture. (Here's a link to that lecture... L16 X86 Debug.) Run disassemble, stepi, and nexti. Run with disassemble-next-line turned on. Set a breakpoint or two at hex locations, and run to those breakpoints. Examine memory to see what's in the stack. Use the info regs commmand to get more information about the registers. Then use the examine (x) command to actually display the stack frame. Remember, the x command prints memory contents from small addresses to large addresses, so they appear "upside down" compared to the lecture notes. Can you figure out a single examine command to print myfunc's stack frame?
Next, investigate the info frame command. Does the information info frame prints out provide insight into the current stack frame? Try the gdb up and down commands to see what influence that has on the info frame results.
Can you figure out how to print out the value of parameters such as "a" or "b" using the "x" command? What about local variable "c"? Can you do this on the version of prog that has debug turned off?
Project 3 is the "bomb" lab. The bomb consists of a C program that prompts for input from the terminal. If you enter the correct answer, you get to the next level. If you do not enter the correct answer, the program prints an error message that starts with "Boom!" and then quits.
Get your custom / personalized bomb at the Section A or Section B web page. Download the tar file associated with your name and un-tar it. This will create a bomb<xxx> directory. Change to that directory, and try running your bomb by typing ./bomb. If you get a Permission denied message, type the command chmod +x bomb, and try again. You should get a message that looks like...
Welcome to my fiendish little bomb. You have 6 phases with which to blow yourself up. Have a nice day!
The terminal will then open up to give you a chance to type a secret key phrase. If you type the corret secret phrase, the bomb will then go forward to the next phase... another secret for you to figure out. If you type the wrong phrase in, then you get a message that says:
BOOM!!! The bomb has blown up.
Blowing up your bomb is a bad thing. You don't want that to happen too much. See if you can figure out a way to run the bomb code in gdb, and set a breakpoint to stop before it blows up.
In order to completely defuse the bomb, you have to figure out the correct value to type in for each phase. You might try to do this by trial and error, but there are literally trillions of possibilities for the first phase... you wouldn't even get through the first phase by the time the project was due!
A better methodology is to use some of the skills taught in this class to help you figure out the right answers. First, you can look at the top level code to get some idea of how the bomb works. There is a "bomb.c" included in your tar file.
Notice that you are not given the code for the functions that actually check your result to see if it is correct. You have to figure out what the program does without the code. How can you do that?
One big hint is to remember what we learned about the gdb debugger.
Good luck, and don't blow up too much!
We're going to give the TA's another break this week... no lab report! In fact, we aren't even going to grade this lab. Your work in this lab will be reflected in how well you do on project 3.