IDA Pro function stack frame view

Question

IDA Pro displays certain buffer or padding above (at lower addresses) local variables in stack frame view. For instance:

Example 1.
The following screen shot of stack frame view shows 12 bytes (included in the red box) buffer:

Example 2.
The following screen shot of a different stack frame view shows 12 bytes buffer again:

I understand that IDA marked it as db ?; undefined because it couldn't figure out how it was used. I also realize that IDA automatically calculates size of a stack frame by monitoring ESP. I would assume it might have something to do with non-volitile register save area. However, in Example 1 it clearly shows Saved regs: 0 and in Example 2 it shows Saved regs: 4. I am puzzled, and here go my questions:

Why does IDA Pro display certain buffer or padding above (at lower addresses) local variables in stack frame view? Is it a coincidence that both views show exactly 12 bytes buffer? Is it something particular to certain calling convention or complier?

Answer 1

IDA keeps track of the value of the stack pointer (ESP) throughout its static analysis of the entire function. The greatest negative value of ESP (relative to the beginning of the function) is used to determine the size of the stack frame.

As for why the stack frames you posted have "undefined" bytes at the top, it's because IDA couldn't automatically determine if or how those stack offsets were being used.

Answer 2

Thank you all so much for your answers and comments. While reading your comments and preparing to update my question, I found the answer.

I must give credit to Igor Skochinsky, who asked me to provide functions' prolog instructions. Both functions use the cdecl calling convention. However, calling convention has nothing to do with this buffer. This is what the prolog looks like:

push    ebp
mov     ebp, esp
sub     esp, <size of local vars>
push    ebx
push    esi
push    edi

This buffer reflects three push instructions for registers EBX, ESI, EDI. These registers are categorized as Callee Saved Registers and this "buffer" is called Non-Volatile Register Save Area.

In accordance to x86 convention (it is also applicable to x64), registers are divided into Caller Saved Registers and Callee Saved Registers.

Caller saved registers are also known as volatile registers. Those are core CPU registers such as EAX, EDX, and ECX. A calling function (Caller) is responsible for saving volatile registers onto usually runtime stack before making a call.

Callee saved registers are known as non-volatile registers. Those are core CPU registers such as EBX, ESI, EDI, ESP, and EBP. It is assumed by convention, that values in those registers will be preserved by a callee function. In case any of the non-volatile registers are going to be used within a callee, the callee is responsible to save the registers onto runtime stack. In addition, the callee is responsible to restore those registers before returning to a caller function.

The way volatile and non-volatile registers used is rather compiler driven. The following paper x86 Assembly Guide describes Caller and Callee rules in more detail.

Answer 3

The screenshots shows that u are examining IDA's detailed stack view.

IDA gives a name to every byte that is accessed directly in the function, any other bytes remain undefined.

Calling convention ? Give us the prologue and the epilogue of this subroutine so we can see how the stack is allocated and cleaned.

So if this is a stack frame of a normal application written in high level language (not malware nor written in assembly by hand) and not calling convention specific then i think we can agree that the compiler allocated more stack space than this function needs for some reason.

I dont think it is a "must" to know why the compiler did this, but thats your choice.