stack operations on a basic C program

Im disassembling this basic C code, trying to figure out what operations are done on the stack. Im doing in it on a vm, 32 bit, gcc 4.4.3, ubuntu based distro. I compiled the code with this flags.

gcc -ggdb -mpreferred-stack-boundary=2 -fno-stack-protector -o ExploitMe ExploitMe.c

#include<stdio.h>
#include<string.h>

main(int argc, char **argv)
{
        char buffer[80];

        strcpy(buffer, argv[1]);

        return 1;
}

The problems is that i cannot figure out why on operation 3, the stack pointer is moved 0x58, the char is 80 characters long, shouldnt it be 0x50 ?

dump of assembler code for function main:
   0x080483e4 <+0>: push   %ebp
   0x080483e5 <+1>: mov    %esp,%ebp
=> 0x080483e7 <+3>: sub    $0x58,%esp
   0x080483ea <+6>: mov    0xc(%ebp),%eax
   0x080483ed <+9>: add    $0x4,%eax
   0x080483f0 <+12>:mov    (%eax),%eax
   0x080483f2 <+14>:mov    %eax,0x4(%esp)
   0x080483f6 <+18>:lea    -0x50(%ebp),%eax
   0x080483f9 <+21>:mov    %eax,(%esp)
   0x080483fc <+24>:call   0x804831c <strcpy@plt>
   0x08048401 <+29>:mov    $0x1,%eax
   0x08048406 <+34>:leave  
   0x08048407 <+35>:ret    
End of assembler dump.

Im stuck on it, i see later that is taking the exected lenght but what is the program making between those ops ?¿

  0x080483f6 <+18>:lea    -0x50(%ebp),%eax

Thank you

The compiler is free to arrange the stack however it sees fit.

The other 8 bytes are for the arguments to strcpy. Rather than push them on to the stack, the compiler has realised that it can simply subtract an extra 8 bytes from the stack pointer and then store the registers to memory. This means that the stack pointer only has to be adjusted once.

it is probably allocating a couple more locations for storing the passed in parameters (argv, argc). and/or it needs some more local storage. Compilers do whatever they want to implement the high level code, the same code will produce dozens/hundreds of different assembly langauge sequences depending on the compiler, version, and optimization settings as well as configure/build settings when the compiler itself was compiled.

You often see this sort of a stack frame though and usually due to a combination of performance and instruction set features/limitations. Much easier to code and debug if you move the stack pointer once or make a copy of it with another register, within the function everything is referenced to one static point while the prepparing, calling, and cleaning up of functions messes with the real stack pointer.

You will often also see that the stack frame leaves room for the passed in parameters and other local variables even if optimization has removed the need for those variables to actually spend any time on the stack. Up front the need for a stack frame and size is determined and optimization comes later and the compiler doesnt always go back and realize that if it makes another pass on the function it can make the stack frame smaller. Likewise the compiler writer can more easily debug if they know that their stack frame always starts with passed in parameters then the local variables in order, very fast and easy to read and debug the code, just an example.

Bottom line though is Oli's answer, the compiler can do whatever it wants so long as it implements your code. My extension to that is the output from the same high level code varies widely depending on the compiler and options. And it is rarely perfectly optimized.