Yeah, it's been broken forever. So long that instead of fixing it by default that they added an argument to fix it if you want. I think that basically means the de-facto ABI is that the stack is aligned to 16 bytes on x86, despite what the ABI actually says.
If you want GCC to follow the ABI, you can use this argument or per-function attribute: -mstackrealign
Realign the stack at entry. On the Intel x86, the -mstackrealign
option will generate an alternate prologue and epilogue that realigns
the runtime stack if necessary. This supports mixing legacy codes that
keep a 4-byte aligned stack with modern codes that keep a 16-byte stack
for SSE compatibility. See also the attribute "force_align_arg_pointer", applicable to individual functions.
http:// gcc.gnu. org/ml/ gcc/2007- 12/msg00503. html gcc.gnu. org/bugzilla/ show_bug. cgi?id= 33721
http://
Yeah, it's been broken forever. So long that instead of fixing it by default that they added an argument to fix it if you want. I think that basically means the de-facto ABI is that the stack is aligned to 16 bytes on x86, despite what the ABI actually says.
If you want GCC to follow the ABI, you can use this argument or per-function attribute:
-mstackrealign
"force_ align_arg_ pointer" , applicable to individual functions.
Realign the stack at entry. On the Intel x86, the -mstackrealign
option will generate an alternate prologue and epilogue that realigns
the runtime stack if necessary. This supports mixing legacy codes that
keep a 4-byte aligned stack with modern codes that keep a 16-byte stack
for SSE compatibility. See also the attribute