I am trying to get a clear picture of who (caller or callee) is reponsible of stack alignment. The case for 64-bit assembly is rather clear, that it is by caller.
Referring to System V AMD64 ABI, section 3.2.2 The Stack Frame:
The end of the input argument area shall be aligned on a 16 (32, if __m256 is passed on stack) byte boundary.
In other words, it should be safe to assume, that for every entry point of called function:
16 | (%rsp + 8)
holds (extra eight is because call implicitely pushes return address on stack).
How it looks in 32-bit world (assuming cdecl)? I noticed that gcc places the alignment inside the called function with following construct:
and esp, -16
which seems to indicate, that is callee’s responsibility.
To put it clearer, consider following NASM code:
global main
extern printf
extern scanf
section .rodata
s_fmt db "%d %d", 0
s_res db `%d with remainder %dn`, 0
section .text
main:
start 0, 0
sub esp, 8
mov DWORD [ebp-4], 0 ; dividend
mov DWORD [ebp-8], 0 ; divisor
lea eax, [ebp-8]
push eax
lea eax, [ebp-4]
push eax
push s_fmt
call scanf
add esp, 12
mov eax, [ebp-4]
cdq
idiv DWORD [ebp-8]
push edx
push eax
push s_res
call printf
xor eax, eax
leave
ret
Is it required to align the stack before scanf is called? If so, then this would require to decrease %esp by four bytes before pushing these two arguments to scanf as:
4 bytes (return address) 4 bytes (%ebp of previous stack frame) 8 bytes (for two variables) 12 bytes (three arguments for scanf) = 28
Advertisement
Answer
GCC only does this extra stack alignment in main; that function is special. You won’t see it if you look at code-gen for any other function, unless you have a local with alignas(32) or something.
GCC is just taking a defensive approach with -m32, by not assuming that main is called with a properly 16B-aligned stack. Or this special treatment is left over from when -mpreferred-stack-boundary=4 was only a good idea, not the law1.
The i386 System V ABI has guaranteed/required for years that ESP+4 is 16B-aligned on entry to a function. (i.e. ESP must be 16B-aligned before a CALL instruction, so args on the stack start at a 16B boundary. This is the same as for x86-64 System V.) ESP % 16 == 0 before a call, ESP % 16 == 12 on function entry, after a call.
The ABI also guarantees that new 32-bit processes start with ESP aligned on a 16B boundary (e.g. at _start, the ELF entry point, where ESP points at argc, not a return address), and the glibc CRT code maintains that alignment.
As far as the calling convention is concerned, EBP is just another call-preserved register. But yes, compiler output with -fno-omit-frame-pointer does take care to push ebp before other call-preserved registers (like EBX) so the saved EBP values form a linked list. (Because it also does the mov ebp, esp part of setting up a frame pointer after that push.)
Perhaps gcc is defensive because an extremely ancient Linux kernel (from before that revision to the i386 ABI, when the required alignment was only 4B) could violate that assumption, and it’s only an extra couple instructions that run once in the life-time of the process (assuming the program doesn’t call main recursively).
Unlike gcc, clang assumes the stack is properly aligned on entry to main. (clang also assumes that narrow args have been sign or zero-extended to 32 bits, even though the current ABI revision doesn’t specify that behaviour (yet). gcc and clang both emit code that does in the caller side, but only clang depends on it in the callee. This happens in 64-bit code, but I didn’t check 32-bit.)
Look at compiler output on http://gcc.godbolt.org/ for main and functions other than main if you’re curious.
I just updated the ABI links in the x86 tag wiki the other day. http://x86-64.org/ is still dead and seems to be not coming back, so I updated the System V links to point to the PDFs of the current revision in HJ Lu’s github repo, and his page with links.
Note that the last version on SCO’s site is not the current revision, and doesn’t include the 16B-stack-alignment requirement.
History of the ABI change from 4 to 16-byte alignment
Footnote 1:
Adding a 16-byte alignment requirement to the i386 SysV ABI was sort of an accident; GCC maintained 16-byte alignment for performance reasons (so for example 8-byte double would never be split across a cache line boundary).
See also a section at the bottom of my answer on Why does the x86-64 / AMD64 System V ABI mandate a 16 byte stack alignment? for more detail.
In some GCC version, SSE/SSE2 code-gen started using movaps to spill/reload __m128 variables to the stack, without manually aligning the incoming ESP. This turned the tuning choice into a requirement, but it wasn’t detected until libraries with code like that were widely deployed in some long-term-stable Linux distros.
Faced with this choice, GCC devs / ABI maintainers chose the least-bad path of making it an official requirement. This broke existing hand-written asm that calls other functions.
See https://sourceforge.net/p/fbc/bugs/659/ for some history, and my comment on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838#c91 for an attempt at summarizing the unfortunate history of how i386 GNU/Linux + GCC accidentally got into a situation where a backwards-incompat change to the i386 System V ABI was the lesser of two evils.
Most BSD versions and i386 MacOS did not adopt this ABI change, and still don’t require 16-byte stack alignment. GCC may default to -mpreferred-stack-boundary=4 for those targets, but code-gen for alignas(16) char buf[16]; (or __m128 locals that get spilled from regs) needs to manually align ESP inside functions in case it wasn’t to start with.
So really this bump from 4 to 16-byte alignment was a change for Linux, mostly not other OSes. That might be another reason to simplify GCC’s source code and always include the extra stack-alignment code in main for 32-bit targets. At this point 32-bit x86 for Linux is obsolete enough that it’s not worth changing now.