-1

Consider the following program:

int main()
{
   int arr[8];
}

When compiling with gcc 9.3.0 on linux 20 the disassembly of the file looks like this at the beginning (this is NOT the whole assembly of the code above!):

┌ 72: int dbg.main (int argc, char **argv, char **envp);
│           ; var int[8] arr @ rbp-0x30
│           ; var int64_t canary @ rbp-0x8
│           0x00001169      f30f1efa       endbr64                     ; test.c:2 { ; int main();
│           0x0000116d      55             push rbp
│           0x0000116e      4889e5         mov rbp, rsp
│           0x00001171      4883ec30       sub rsp, 0x30

Why is the assembler allocating 0x30 = 48 bytes on the stack when arr is only 8 ints = 8 * 4 bytes long (sub rsp, 0x30)?

Hell stormer
  • 413
  • 1
  • 4
  • 14
  • What's this "format" your disassembler is talking about? https://godbolt.org/z/Kq9jzs shows GCC9.3 `-fstack-protector-strong` starting with the instructions you show, but it never accesses `[rbp-0x28]`. – Peter Cordes Dec 01 '20 at 03:09
  • Yes, I understand that's not the whole asm file, but I'm curious how you got any asm from that C source that a disassembler with partial decompiler features (identifying local vars) would find anything at `rbp-0x28`. That's the only mystery to me, everything else is normal. So as Jester commented, it makes me wonder if you actually disassembled a different program that did something with the 8 bytes left after aligning the array below a stack canary. – Peter Cordes Dec 01 '20 at 15:38
  • From your edit (and deleting your previous comment), I guess that was the case. The disassembler's comments make sense now. – Peter Cordes Dec 01 '20 at 15:39
  • 1
    Im sorry I just noticed. You were right. The format probably belonged to a printf I deleted from my source file after disassembling. I edited my question – Hell stormer Dec 01 '20 at 15:40

1 Answers1

7

That's:

Total: 48 bytes.

Nate Eldredge
  • 48,811
  • 6
  • 54
  • 82
  • 4
    But mostly because it's not optimized. Since it is a leaf function it does not need to align the stack, nor does it need any allocation as long as locals fit into the red zone. Also the `format` mentioned in the comment seems to indicate this is assembly for a different program than shown. – Jester Nov 30 '20 at 23:15
  • 2
    @Jester: For that matter, `arr` could be optimized out altogether; with optimization you just get `xor eax, eax ; ret`. I found the `format` mysterious because it appears to overlap `arr`. – Nate Eldredge Nov 30 '20 at 23:25