CS 208: Computer Organization & Architecture

More C

Goals for today

• More experience with C strings (i.e. null-terminated char arrays)
• Intro to pointers/addresses in C, including the mysterious "const char *" from last time
• Intro to debugging with lldb
• Investigating the structure of stack frames as constructed by the C compiler
• Fun with buffer overflows

Debugging with lldb

The LLDB Debugger is a terminal-based debugger that enables you to run your programs, stop them in the middle of execution (i.e. stop at breakpoints), examine variables while the program is stopped, and continue execution. Here's the very beginning of getting to know lldb.

Note that today we'll use the clang compiler and lldb instead of their more venerable friends gcc and gdb, because clang + lldb supports what we want to do on a Mac without much trouble, whereas the setup for gcc + gdb in our lab would be much more complicated. The steps here, though, will be essentially the same with gcc + gdb on other systems (notably Linux).

First, let's watch the Fibonacci numbers evolve.

• Grab this slightly modified functions.c from the other day. Take a quick look at it to remind yourself what it does. Note that main() in this version just calls fibonacci(10) instead of calling fibonacci(k) for lots of values of k.
• Compile it:
  clang -g -o functions functions.c
  That "-g" is essential; it generates "debugging symbols" in the executable so you can use lldb effectively.
• Launch lldb:
  lldb functions
• Run the program inside lldb:
  (lldb) r
  That "(lldb)" is the lldb prompt—you don't have to type it.
• List the contents of main:
  (lldb) list main
  You can then hit Enter as many times as you want to see more code beyond the first few lines of main.
• List the contents of fibonacci. Take note of the line number that's given for the line inside the loop that says "previous = current;".
• Set a breakpoint at that line number:
  (lldb) b 43
  (or whatever line number lldb is showing you—43 was what it showed me).
• Run the program up until the breakpoint:
  (lldb) r
  .
• Look at the current values of the local variables and the parameter:
  p n p previous p current p new
  Did you get what you expected?
• Continue the program until it hits the breakpoint again:
  (lldb) c
  .
• Examine the variables again. Still looking good?
• Delete the breakpoint. First, list your breakpoints:
  (lldb) breakpoint list
  Then pick the number of the breakpoint from the list (probably 1 in this situation) and then do this:
  (lldb) breakpoint delete 1

Next, let's watch a string change in squashCharacterInString.

• List the contents of the squashCharacterInString, and set a couple breakpoints: one at the "if (string[k] == character) {" line, and one at the very bottom of the function "}". This will make the program stop at the beginning of each iteration of the loop, and also just before the function returns.
• Run the program up to the first breakpoint.
• Examine the values of character, n, k, and string.
• Continue the program up to the next time it stops. Examine k and string again. Are they looking as expected?
• Do that again a few times.
• When you hit the breakpoint at the end of the function, does string look like it should?
• Done? Go ahead and quit lldb:
  (lldb) q

Strings, pointers, and stack frames

Before jumping in here, think about these two ideas:

• Remember what a stack frame is for, and what kinds of information you put in one.
• When you declare a character array (e.g. char a[10];), the name of the array is, more or less, synonymous with the address of the first byte in the array.

With those ideas in mind, keep working with functions.c.

• When in lldb, set a breakpoint in fibonacci at the return statement. Run the program, stopping at the breakpoint. Examine the variables n, previous, current, and new.
• Still paused at the breakpoint, try this:
  p &n p &previous p &current p &new
  This will show you the memory addresses where the parameter n and the three local variables are stored. Where are they in relation to each other in memory? (It might be worth your while to draw a picture.)
• Delete the fibonacci breakpoint and add a breakpoint somewhere in factorialRecursive. Watch the variables n and previousResult in factorialRecursive evolve as you stop each time, but more importantly, watch their addresses change. What's going on? (Think about stack frames and recursion.)
• Now let's compare addresses of related variables. First, what's the address of n in main, and the address of n in fibonacci? Are they the same or different? Second, what's the address of word in main, and the address of s in squashCharacterInString? Are they the same or different? Again, what's going on? (We will debrief on this question soon.)

Trouble in stackframeland

Finally, let's turn our attention to the function makeTrouble.

• What does the call to makeTrouble("dog", "cat") do?
• Try changing that call to be makeTrouble("dog", "black rhinoceros"). What happens, and why?
• Leave the "black rhinoceros" in place, but this time, compile the program like this:
  clang -g -o functions -fno-stack-protector -D_FORTIFY_SOURCE=0 -fno-sanitize=memory functions.c
  What's happening here is that we're disabling three different types of security protections that are enable by default (for good reason). But something very interesting happens when we do this. Try it out, and try to explain in detail what you're seeing and why you're seeing it.