Why does GCC order integers on the stack in this way? - c++

Question

There are some existing questions about GCC ordering of variables on the stack. However, those usually involve intermixed variables and arrays, and this is not that. I'm working with the GCC 9.2.0 64-bit release, with no special flags on. If I do this:
#include <iostream>
int main() {
int a = 15, b = 30, c = 45, d = 60;
// std::cout << &a << std::endl;
return 0;
}
Then the memory layout is seen as in the disassembly here:
0x000000000040156d <+13>: mov DWORD PTR [rbp-0x4],0xf
0x0000000000401574 <+20>: mov DWORD PTR [rbp-0x8],0x1e
0x000000000040157b <+27>: mov DWORD PTR [rbp-0xc],0x2d
0x0000000000401582 <+34>: mov DWORD PTR [rbp-0x10],0x3c
So: The four variables are in order at offsets 0x04, 0x08, 0x0C, 0x10 from the RBP; that is, sequenced in the same order they were declared. This is consistent and deterministic; I can re-compile, add other lines of code (random printing statements, other later variables, etc.) and the layout remains the same.
However, as soon as I include a line that touches an address or pointer, then the layout changes. For example, this:
#include <iostream>
int main() {
int a = 15, b = 30, c = 45, d = 60;
std::cout << &a << std::endl;
return 0;
}
Produces this:
0x000000000040156d <+13>: mov DWORD PTR [rbp-0x10],0xf
0x0000000000401574 <+20>: mov DWORD PTR [rbp-0x4],0x1e
0x000000000040157b <+27>: mov DWORD PTR [rbp-0x8],0x2d
0x0000000000401582 <+34>: mov DWORD PTR [rbp-0xc],0x3c
So: A scrambled-up layout with the variables at offsets now respectively at 0x10, 0x04, 0x08, 0x0C. Again, this is consistent with any re-compiles, most random code I think to add, etc.
However, if I just touch a different address like so:
#include <iostream>
int main() {
int a = 15, b = 30, c = 45, d = 60;
std::cout << &b << std::endl;
return 0;
}
Then the variables get ordered like this:
0x000000000040156d <+13>: mov DWORD PTR [rbp-0x4],0xf
0x0000000000401574 <+20>: mov DWORD PTR [rbp-0x10],0x1e
0x000000000040157b <+27>: mov DWORD PTR [rbp-0x8],0x2d
0x0000000000401582 <+34>: mov DWORD PTR [rbp-0xc],0x3c
That is, a different sequence at offsets 0x04, 0x10, 0x08, 0x0C. Once again, this is consistent as far as I can tell with recompilations and code changes, excepting if I refer to some other address in the code.
If I didn't know any better, it would seem like the integer variables are placed in declaration order, unless the code does any manipulation with addressing, at which point it starts scrambling them up in some deterministic way.
Some responses that will not satisfy this question are as follows:
"The behavior is undefined in the C++ standard" -- I'm not asking about the C++ standard, I'm asking specifically about how this GCC compiler makes its decision on layout.
"The compiler can do whatever it wants" -- Does not answer how the compiler decides on what it "wants" in this specific, consistent case.
Why does the GCC compiler layout integer variables in this way?
What explains the consistent re-ordering seen here?
Edit: I guess on closer inspection, the variable whose address I touch is always placed in [rbp-0x10], and then the other ones are put in declaration order sequence after that. Why would that be beneficial? Note that printing the values of any of these variables don't seem to trigger the same re-ordering, from what I can tell.

Answer 1

You should compile your daniel.cc C++ code with g++ -O -fverbose-asm -daniel.cc -S -o daniel.s and look into the generated assembler code daniel.s
For your first example, a lot of constants and slots in your call frame have disappeared, since optimized:
.text
.globl main
.type main, #function
main:
.LFB1644:
.cfi_startproc
endbr64
subq $24, %rsp #,
.cfi_def_cfa_offset 32
# daniel.cc:2: int main() {
movq %fs:40, %rax # MEM[(<address-space-1> long unsigned int *)40B], tmp89
movq %rax, 8(%rsp) # tmp89, D.41631
xorl %eax, %eax # tmp89
# daniel.cc:3: int a = 15, b = 30, c = 45, d = 60;
movl $15, 4(%rsp) #, a
# /usr/include/c++/10/ostream:246: { return _M_insert(__p); }
leaq 4(%rsp), %rsi #, tmp85
leaq _ZSt4cout(%rip), %rdi #,
call _ZNSo9_M_insertIPKvEERSoT_#PLT #
movq %rax, %rdi # tmp88, _4
# /usr/include/c++/10/ostream:113: return __pf(*this);
call _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_#PLT #
# daniel.cc:6: }
movq 8(%rsp), %rax # D.41631, tmp90
subq %fs:40, %rax # MEM[(<address-space-1> long unsigned int *)40B], tmp90
jne .L4 #,
movl $0, %eax #,
addq $24, %rsp #,
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L4:
.cfi_restore_state
call __stack_chk_fail#PLT #
.cfi_endproc
.LFE1644:
.size main, .-main
.type _GLOBAL__sub_I_main, #function
If for whatever reason you really require your call frame to contain slots in a known order, you need to use a struct as an automatic variable (and that approach is portable to other C++ compilers).
If you need to understand why GCC has compiled your code the way it did, download the source code of GCC, read the documentation of GCC internals, study it (it is free software).
You should be interested by GCC developer options, they dump a lot of things regarding the internal state of the compiler.
Once you understood a bit what GCC actually does, subscribe to some GCC mailing list (e.g. gcc#gcc.gnu.org) and ask questions there. Alternatively, code your GCC plugin to improve its behavior, change the organization of the call frame, add dumping routines.
If you need to understand or improve GCC, budget several months of full time work, and read the Dragon book before.