How To See Into 0x4 %rsp Register Gdb

In my previous mail service I covered a few basics around edifice a C program for debugging, looking at the code list and assembly of the program, setting breakpoints and peeking into the registers.

For Part 2, I'll exist using more gdb commands to explore the assembly lawmaking that's involved in edifice upwards and initializing the stack frame at the start of a function.

Stacking Up

I desire to dig down into every bit of what this program is doing, I'll brainstorm by pulling upwardly the disassembly version of the plan once again.

If I utilize intermission main to prepare a breakpoint at the kickoff of my master function, GDB will be practical and set this breakpoint at the address 0x400575, 15 bytes into the assembled version of main. It'll do this because the showtime 6 instructions of the function are setting upward the stack for the function and normally you can trust that the compiler has done a expert job handling that for you.

I want to really start at the beginning, and then I'm going to instead prepare my breakpoint with a pointer to the first byte of the role with the command break

The first associates instruction seen here is push rbp. This is pushing the value stored in the rbp (base of operations arrow) annals onto the stack, but where is the stack? The rsp (stack arrow) register tell united states of america where the top of the stack currently is.

These first three instructions are building a new call stack frame. Since this program uses libc the program starts by running code to initialize a few things and so calls the chief function that was created in the source code. The compiler adds these instructions to build out the stack frame for the given function.

The stack when printf is being called from main

Every bit mentioned before, the rsp register points to the points to the top of the stack. By running nexti (next instruction), I can execute one machine functioning at a time. After letting push button rbp run, the current value of rbp is added to the tiptop of the stack. While this happens, the stack grows and rsp will be updated to the new top of the stack.

The value of rbp hasn't changed, just the value of rsp is eight bytes smaller. In most CPU architectures the stack grows "downwards" like this, where the lowest call frame represents the current frame.

Peeking Into Memory

Nosotros should at present be able to see the rbp value at the elevation of the frame. Past using the x control to print data in memory, nosotros can take a look at the frame. x has a few useful options, while you're learning GDB they tin be tricky to recall so I recommend keeping a crook sail handy until you've got it downwardly.

To look at the value at the superlative of the stack, I'll use ten/1xg 0x7fffffffda10. This is asking to see ane unit of measurement of information, in hexadecimal format, considering 64-fleck "giant" words. Yous can choose instead to dereference the rsp annals direct in the control by using $rsp for the address.

The value of rbp is indeed at the top of the stack

With the commands covered so far nosotros can more easily audit what each didactics is doing. The next instruction is mov rbp, rsp, this moves the value of rsp into rbp. This is to set the base arrow to the summit of the previous stack frame which is used at the end of a function to restore the previous stack state.

Now rbp and rsp are set to the same value

The next instruction, sub rsp,0x20, lowers the value of rsp by 32 (4 64-scrap words). This is the size of the frame being built for main. Using x once more, I'll look at the 4 words in the stack, plus the side by side give-and-take after (the rbp value that was pushed to the stack).

At that place's already data in this stack! This is data left over from previous execution and is considered uninitialized, as this function doesn't know what data was been left behind here. When gcc warns that 'i' is used uninitialized in this function [-Wuninitialized], it is because the program is using a variable that's not in a known state.

Pointers IRL

The side by side 3 instructions are going to be initializing the new stack frame region using pointers. If you've been dislocated virtually pointers in C, pointers in assembly might help demystify that concept for you. Let's consider the next three instructions:

                      => 0x000000000040056e <+8>:     mov    DWORD PTR [rbp-0x14],edi                                      0x0000000000400571 <+11>:    mov    QWORD PTR [rbp-0x20],rsi                                      0x0000000000400575 <+15>:    mov    DWORD PTR [rbp-0x4],0x0

These are assignment operators that refer to addresses relative to a retentiveness address that is stored in a register. In this instance they are modifying the data in the new stack frame (addresses below rbp). Sometime before primary was called, the edi and rsi registers were set to some values that the compiler wants kept effectually.

The kickoff instruction here is setting a 32-fleck (Double Word) at the memory address 20 bytes beneath rbp. I'll need to give 10 a w parameter then that it'll know I'm now looking for a 32-bit word.

Basically the same thing going on for the next instruction, simply setting the memory address 32 bytes below the base pointer to the 64-fleck value currently in rsi.

These registers (*di, *si) are index registers that can be used for various string operations. They are also part of the x86_64 calling convention to be used when calling functions. In this case, these registers comprise the parameters for chief, my argc and argv variables.

Nosotros can utilize the print command to look at the variables as they were named in the source code. The & operator tin be used similar to how it used in C to verify that these variables are stored at those locations in the stack.

The next instruction, mov DWORD PTR [rbp-0x4],0x0, is the i variable used within the for loop inside of master, here being initialized to the value we specified, 0.

At this point the stack for chief is initialized and main is ready to practice its thing. In the next post I'll proceed the GDB exploration to investigate the residuum of what this function is up to!