cd cs31/weeklylab pwd mkdir week05 ls cd week05 pwd cp -r ~lammert/public/cs31/week05/* . ls Makefile gdb_examples/ memparts.c pointers.c valgrind_examples/
So far we have looked at special forms of Memory addressing in IA32. We have seen examples such as these:
(%eax) # get val @ address in %eax -4(%eax) # get value @ offset -4 from address in %eax
The General Memory Addressing form for IA32 is the following:
D(Rb,Ri,S) # get value @ Rb + S*Ri + D
where,
Rb: Base register
Ri: Index register
S: Scale factor
D: Constant "displacement"
For example, an instruction could specify a memory operand as:
addl 8(%ecx, %eax, 4), %edx # R[%edx] <-- M[R[%ecx] + 4*R[%eax] + 8]There are a lot of Special Cases of this general form (not all 4 values need to be present):
D(Rb,Ri,S) # Mem[Reg[Rb]+S*Reg[Ri]+ D] The General Form (Rb,Ri,S) # Mem[Reg[Rb]+S*Reg[Ri]] (Rb,Ri) # Mem[Reg[Rb]+Reg[Ri]] D(Rb,Ri) # Mem[Reg[Rb]+Reg[Ri]+D] (,Ri,S) # Mem[S*Reg[Ri]] D(,Ri,S) # Mem[S*Reg[Ri] + D] (Rb) # Mem[Reg[Rb]] we have already seen this form: (%eax) D(Rb) # Mem[Reg[Rb]+D] we have already seen this form: -8(%ebp) D # Mem[D] we have already seen this form: $10
Load effective address: leal S,D # D<--&S, where D must be a register, and S is a Memory operand. It's often used to implement C's address of (&) operator.
leal looks like a mov instr, but does not access Memory. Instead, it takes advantage of the addressing circuitry and uses it to do arithmetic (as opposed to generating multiple arithmetic instructions to do arithmetic).
(ex) if edx holds the value of x:
leal (%eax),%ecx # R[%ecx]<--&(M[R[%eax]])
# this moves the value stored in %eax to %ecx
The key is that the address of (M[ at address x ]) is x, so this is moving the value stored in %eax to %ecx; there is no memory access in this instruction's execution.
Examples:
Assume: %eax: x %edx: y leal (%eax), %ecx # R[%ecx] <-- xleal appears a lot in compiler generated code. The compiler sometimes abuses leal to perform basic arithmetic.
leal 6(%eax), %ecx # R[%ecx] <-- x+6 Assume y is a variable on the stack, at address %ebp - 4. leal -4(%ebp), %ecx # R[%ecx] <--- &(M[R[%ebp]-4]]): R[%ecx] <-- &y
$ cat pointers.c int pointers() { int x, y, *ptr; x = 8; ptr = &y; *ptr = 30; x = *ptr + 20; }Lets compile a simple program using pointers and see what its assembly code looks like (or just type make):
$ gcc-4.4 -m32 -S pointers.cLet's cat out the .s file an look at some of the instructions. The thing to note is that when the *ptr is used (ptr is dereferenced), first the value of the ptr variable is obtained (its value is the address of y) and then the value at that address is accessed: a level of indirection.
Here is the code with some annotations around what it is doing (note the use of leal instruction):
$ cat pointers.s pointers: pushl %ebp movl %esp, %ebp subl $16, %esp movl $8, -4(%ebp) # x = 8 leal -8(%ebp), %eax # R[%eax] <--- &(M[R[%ebp]-8]]): R[%eax] <-- &y movl %eax, -12(%ebp) # ptr = &y; movl -12(%ebp), %eax # R[%eax] <-- ptr: R[%eax] <-- &y movl $30, (%eax) # what ptr points to gets 30 movl -12(%ebp), %eax movl (%eax), %eax addl $20, %eax movl %eax, -4(%ebp) leave ret
Let's just run this and see where some things are:
./mempartsThe thing to note now is that heap memory locations (malloc'ed space) and local variable locations (on the stack) are at very different addresses. We will revisit this program later in the semester when we talk about other parts of program memory.
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.
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 ./badprogThe 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.