why is the call stack set up like this?

Answer 1

Is this a debug or release build? I'd expect some padding with the debug builds for detecting Stack Overflows.

Answer 2

Inspecting the stack like this seems like one step too far away. I might suggest loading your program in a debugger, switching to the assembly language view, and single stepping through every machine instruction. Understanding of the CPU stack necessarily requires an understanding of the machine instructions operating on it, and this will be a more direct way to see what's going on.

As others mentioned, the structure of the stack is also highly dependent on the processor architecture you're working with.

Answer 3

Most likely those are stack canaries. Your compiler adds code to push additional data to the stack and read it back afterwards to detect stack overflows.

Answer 4

I'm guessing those values starting with 0x0804 are addresses in your program's code segement (like return addresses for function calls). The ones starting with 0xBF814 that you've labeled as return addresses are addresses on the stack -- data, not code. I'm guessing they're probably frame pointers.

Answer 5

The 0xBF... addresses will be links to the previous stack frame:

0xBF8144D8 : BF8144F8 //return address for trace
0xBF8144DC : 0804845A //

0xBF8144F8 : BF814518 //return address for func3
0xBF8144FC : 08048431 //????

0xBF814518 : BF814538 //return address for func2?
0xBF81451C : 0804840F //????

0xBF814538 : BF814558 //return address for func1
0xBF81453C : 080483E8 //????

The 0x08... addresses will be the addresses of the code to return to in each case.

I can't speak for the other stuff on the stack; you would have to step through the assembly language and see exactly what it is doing. I guess that it is aligning the start of each frame to a specific alignment so that __attribute__((align)) (or whatever it's called these days...) works.

Answer 6

The compiler uses EBP to store the frame's base address. It's been a while so I looked at this, so I may get the details a bit wrong, but the idea is like this.

You have three steps when calling a function:

1. The caller pushes the function's parameters onto the stack.
2. The caller uses the call instruction, which pushes the return address onto the stack, and jumps to the new function.
3. The called function pushes EBP onto the stack, and copies ESP into EBP:
4. (Note: well behaved functions will also push all the GPRs onto the stack with PUSHAD)

push EBP
mov EBP, ESP

When the function returns it:

1. pops EBP
2. executes the ret instruction, which pops off the return address and jumps there.

pop EBP
ret

The question is, why is EBP pushed, and why does ESP get copied into it?

When you enter the function ESP points to the lowest point on the stack for this function. Any variables you declare on the stack can be accessed as [ESP + offset_to_variable]. This is easy! But note that ESP must always point to the top of the stack, so when you declare a new variable on the stack, ESP changes. Now [ESP + offset_to_variable] isn't so great, because you have to remember what ESP was at the time the variable was allocated.

Instead of doing that, the first thing the function needs to do is to copy ESP into EBP. EBP won't change during the life of the function, so you can access all variables using `[EBP + offset_to_variable]. But now you have another problem, because if the called functions calls another function, EBP will be overwritten. That's why before copying EBP it needs to be saved onto the stack, so that it can be restored before the returning to the calling function.

Answer 7

As already pointed out, the 0xBF... are frame pointers and 0x08... return addresses.

The padding is due to alignment issues. Other unrecognized values are also padding as the stack is not initalized to zero or any other value. Uninitialized variables and unused padding space will contain whatever bytes are in those memory locations.