Lab 2: Debugger
The goals of this assignment are to do some basic investigation of
the x86_64 architecture and assembly language, and to refresh your
understanding of how to use the debugger gdb.
We'll walk you through the process of exploring some buggy code (provided for you!), using a variety of GDB commands and techniques. There are links to more references later on the page.
Grading
This lab is worth a total of 51 points, divided as follows:
| Part | Points |
|---|---|
| 1 | 16 |
| 2 | 17 |
| 3 | 18 |
Due Date
Due: Friday, February 13 at 11:59 PM
This is a one-week lab!
Resources & References
- Our help page on debugging (which might look familiar to you from CS 70).
- GDB Quick Reference Card. If you print it double-sided, you can fold it in thirds and even fit it in a pocket :)
- Debugging with
GDB
(PDF),
the full manual for
gdb.
Compiler Options
There are a number of compiler flags (for clang and gcc) that tell the compiler to provide more useful information for debugging. Here are a few.
-g- The
-gflag tells the compiler to generate debug information, which allows the debugger to find and show you the actual lines of code that are being executed as you're running or stepping through a program. You always want to use the-gflag when you're debugging a problem, but it's also a useful thing to use all the time when writing software, although you probably don't want to use it for production code. -Og- If you must have some optimization (not likely to be an issue with the code you're writing for classes), the
-Ogflag tells the compiler to only lightly optimize the code it produces, making it easier to debug, but slightly smaller. -S- The
-Sflag goes through all the stages of compiling a program prior to assembling it (i.e., building a.ofile). Instead, it leaves you with the generated assembly code. Inspecting the assembly code can tell you how the compiler has interpreted your code for the machine. Using the-Sflag alongside various levels of optimization can help you see what the compiler inlines or throws away, which can be helpful if a bug shows up in an optimized binary but not in a non-optimized (or less optimized) build.
Note: This lab must be run on wilkes. If you run it on a
different machine, you may get incorrect (or at least different) answers.
Steps
(When logged in, completion status appears here.)