3

To get a better understanding of binary files I've prepared a small c++ example and used gdb to disassemble and look for the machine code.

The main() function calls the function func():

int func(void)
{
    int a;
    int b;
    int c;
    int d;
    d = 4;
    c = 3;
    b = 2;
    a = 1;
    return 0;
}

The project is compiled with g++ keeping the debugging information. Next gdb is used to disassemble the source code. What I got for func() looks like:

0x00000000004004cc <+0>:    push   %rbp
0x00000000004004cd <+1>:    mov    %rsp,%rbp
0x00000000004004d0 <+4>:    movl   $0x4,-0x10(%rbp)
0x00000000004004d7 <+11>:   movl   $0x3,-0xc(%rbp)
0x00000000004004de <+18>:   movl   $0x2,-0x8(%rbp)
0x00000000004004e5 <+25>:   movl   $0x1,-0x4(%rbp)
0x00000000004004ec <+32>:   mov    $0x0,%eax
0x00000000004004f1 <+37>:   pop    %rbp
0x00000000004004f2 <+38>:   retq

Now my problem is that I expect that the stack pointer should be moved by 16 bytes to lower addresses relative to the base pointer, since each integer value needs 4 bytes. But it looks like that the values are putted on the stack without moving the stack pointer.

What did I not understand correctly? Is this a problem with the compiler or did the assembler omit some lines?

Best regards,
NouGHt

NouGHt
  • 31
  • 3

1 Answers1

4

There's absolutely no problem with your compiler. The compiler is free to choose how to compile your code, and it chose not to modify the stack pointer. There's no need for it to do so since your function doesn't call any other functions. If it did call another function then it would need to create another stack frame so that the callee did not stomp on the caller's stack frame.

As a general rule, you should avoid trying to make any assumptions on how the compiler will compile your code. For example, your compiler would be perfectly at liberty to opimize away the body of your function.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Thanks, exactly that was the point. After calling an additional function everything looks as expected. – NouGHt Feb 27 '13 at 13:00
  • 2
    @NouGHt: Everything is as expected. The base pointer (`%rbp`) is stored for later recovery at the top of the stack. `%rbp` then has the old top of the stack loaded in to it. Then the stack is accessed using addresses relative to `%rbp` and all the local variables are set. Finally the base pointer is returned to its original value and `0` is returned in `%eax`. The stack pointer is not changed, because the code contains nothing that could possibly clobber the local variables, so there is no need to communicate their positions to other code by setting the stack pointer to some value. – Mankarse Feb 27 '13 at 13:34