Nate Eldredge
2020-12-01 07:08:47
That's:
32 bytes for your array
8 bytes for a stack canary
A further 8 bytes to ensure 16-byte stack alignment.
Total: 48 bytes.
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)?
That's:
32 bytes for your array
8 bytes for a stack canary
A further 8 bytes to ensure 16-byte stack alignment.
Total: 48 bytes.
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
formatmentioned in the comment seems to indicate this is assembly for a different program than shown.@Jester: For that matter,
arrcould be optimized out altogether; with optimization you just getxor eax, eax ; ret. I found theformatmysterious because it appears to overlaparr.