8

I have a function:

void func(int a)
{
    int x = a+2;
}

In the assembly code, in function prolog:

push %ebp
mov %esp, %ebp
sub $0x10, %esp

The code only needs to reserve space for x i.e. 4 bytes. But it is reserving 16 bytes. Why is that ? I have always seen it to reserve more space than required.

My guess: it tends to store in 16 bytes. i.e. if I needed say 20 bytes, it will reserve 32 bytes, no matter what.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
Rash
  • 7,677
  • 1
  • 53
  • 74
  • It seems that my guess is wrong because in this link the guy needs only 16 byte space,yet 32 bytes are reserved. http://stackoverflow.com/questions/13430540/please-i-dont-understand-why-sub-0x20-esp-let-me-know – Rash Oct 21 '13 at 05:00
  • Possible duplicate of http://stackoverflow.com/questions/4175281/what-does-it-mean-to-align-the-stack. – Crowman Oct 21 '13 at 05:13
  • Hello @PaulGriffiths This is not a duplicate, as that question explains why you need to align the memory. I am asking why more than required space is reserved in stack ? – Rash Oct 21 '13 at 05:32
  • Aligning the stack pointer is exactly why it's subtracting 16 bytes, here. "Reserving more space" here is merely a side-effect of that. – Crowman Oct 21 '13 at 05:40
  • 1
    I am sorry that I didn't add 1 more line for simplicity, the original code has 1 more line before the "sub" line: and 0xfffffff0, %esp So the aligning was done before allocating space. – Rash Oct 21 '13 at 05:42
  • The important thing is that if the stack pointer needs to be aligned in 16 byte blocks, and your function doesn't align it to a 16 byte block, then any other functions it calls can't properly align it either, since they're not starting from an aligned pointer. If you don't need more than 16 bytes of local storage then obviously this will "give you extra space", but that's not the purpose of what it's doing. – Crowman Oct 21 '13 at 05:45
  • ok I get that. But since the aligning is done before allocating space, why is it that they are still allocating a large chunk of memory. It is obviously not the case that the stack always needs to be aligned. It only needs to be aligned at the beginning which is already done. Still much more space is reserved. Why ? – Rash Oct 21 '13 at 05:52
  • 3
    You not only need to align it once, you need to keep it aligned. That is once you have ensured it's aligned, only ever adjust it such that it remains aligned. Thus the extra space. – Jester Oct 21 '13 at 09:56
  • 3
    Right - if you align it, and then add only four bytes, you've just thrown it out of alignment again. – Crowman Oct 21 '13 at 11:24

1 Answers1

7

This highly depends on your architecture and compiler flags, so it is impossible to point to a single thing and say "this must be it" here. However, I can give you some pointers you may find helpful.

First, consider the stack boundary. You may have heard of the -mpreferred-stack-boundary=X flag to GCC. If not, it basically tells your compiler to prefer your values on the stack to be 2^X bytes each. Your compiler will then try to optimize your program so that these values fit on the stack as best as possible. On the other hand, GCC modifier such as __packed__ will make the compiler try to fit the data in the stack as tightly as possible.

There's also the stack protector. Basically, GCC places dummy values on the stack that make sure buffer overflows can't any harm other than segfaulting your program (which isn't fun, but better than an attacker tacking control of the instruction pointer). You can easily try this out: take any recent version of GCC and let the user overflow a buffer. You'll note that the program exits with a message along the lines of 'stack smashing detected, terminated'. Try compiling your program with -fno-stack-protector, and the allocated local memory on the stack will probably be smaller.

Anonymous
  • 431
  • 3
  • 9
  • Note: this answer is the same as the first half of my answer given here: http://stackoverflow.com/questions/19736213/explain-esp-ebp-in-this-program/19736689#19736689 I wouldn't consider it a duplicate, but you may find it useful nonetheless. – Anonymous Nov 01 '13 at 23:30