Create a week05 subdirectory in your weeklylab subdirectory and copy over some files (note: the cp -r):

    cd cs31/weeklylab		
    pwd
    mkdir week05
    ls
    cd week05
    pwd
    cp -r ~newhall/public/cs31/week05/* .
    ls
    Makefile  gdb_examples/  memparts.c  variables.c  valgrind_examples/

Week 5 lab goals:

1. Example of writing IA32 assembly code in a .s file and then compiling and running it.
2. See an example of where different parts of program memory are
3. Learn gdb to debug segfaults
4. Learn valgrind to find memory access errors

In variables.c is a simple function that has some local variables and returns a value, and in mainprog.c is a main function that makes a call to this function.

$ cat variables.c
$ cat mainprog.c

If you run make it will build an assembly code version of variables.c and then link it into the executable mainprog. Look for this command:

$ gcc-4.4 -m32 -S variables.c

Let's cat out the .s file an look at some of the instructions:

$ cat variables.s

One thing to note is where the local variables are on the stack (see that they are at addresses relative to %ebp). Another is to notice that the return value is copied into register %eax.

Let's try running the mainprog and see what happens.

Next, modify code in variables.s in a way that the function will return a different value. Run make again to link in your new version of variables.s into mainprog executable. Then run and see what happens. Be careful not to modify variables.c or make will rebuild variables.s from it.

The memparts.c program prints out the memory address of different parts of the program: global variables, local variables on the stack, instructions, and heap memory locations for malloc'ed space.

Let's just run this and see where some things are:

./memparts

Notice where local and global variables are located in memory, and notice that heap memory locations (malloc'ed space) and local variables (on the stack) are at very different addresses.

In the code you copied over are two subdirectories with test files for gdb and valgrind. We are going to go over just a couple of these, but see my gdb and valgrind documentation (both linked to below) for more information about using gdb and valgrind and try out some more examples.

Today, we are going to look at some features of gdb for debugging C programs. In particular, looking at a stack trace, moving between frames to examine parameter and argument values, and examining runtime state of a segfaulting program. Again, you can use ddd, but I'm going to show you the gdb commands running gdb.

cd into the gdb_examples subdirectory.

First, run make to build the executables (note they are all compiled with -g).

Let's look through a couple of the example programs in gdb, following along in my GDB Guide.

We are going to look at badprog and segfaulter in gdb. These are listed in the "Sample gdb sessions" part of my gdb guide under run 1: debugging badprog and run 2: debugging segfaulter.

Up the page on this guide are lists of common gdb commands and some examples of how to use them.

cd into the valgrind_examples subdirectory.

Valgrind is a tool for finding heap memory access errors and memory leaks in C and C++ programs. Memory access errors are often very difficult bugs to find, and valgrind helps you easily find errors like reads or writes beyond the bounds of a malloc'ed array, accessing free'ed memory, reading uninitialized memory, and memory leaks (not freeing malloc'ed space before all variables referring to it go out of scope).

To use valgrind, just compile with -g, and run valgrind on your program:

make
valgrind ./badprog

The output at first seems a bit cryptic, but once you see the basics of how to interpret it, it is extremely helpful for finding and fixing memory access errors. Let's look at my Valgrind Guide to see how to interpret some of this valgrind output. This guide contains links to other valgrind resources, and the README file in the code you copied over lists some command line options for running valgrind.

---

Some more information on debugging tools for C: C programming tools: gdb and valgrind

Let's look at Lab 4 together, then you should spend the rest of lab today starting the lab 4 assignment with your partner (see the partner list off the class schedule if you are unsure who your partner is). Start with Part 1, which is a C programming assignment using pointers, and remember this page with information on using gdb and valgrind to debug your C programs.