Login/Register
Responsibility of stack alignment in 32-bit x86 assembly
Asked Answered
Solved linuxgccassemblyx86memory-alignment
C

1

14

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 %d\n`, 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
Caput answered 28/10, 2016 at 14:22 Comment(5)
The 16-byte alignment code that looks like and esp, 0xfffffff0 is usually something that you'll find added to the template code of main. But for every other function alignment is maintained by the calling function. I should point out that for 32-bit code you should follow the System V i386 ABI. Yes, you need to keep the stack 16-byte aligned just prior to a function call like scanf etc – Unionist
x86 stack must be aligned on 4 byte only (generic register size). so usually not need do special tasks for stack align. in x64 - this is caller responsibility for stack align on 16*x before call – Doorjamb
@RbMm: As I understand, the alignment requirement for x86 stack on Linux was increased. The current requirement is 16 bytes (32 if one passes _m256 argument). Section 2.2.2 of ABI now contains this phrase: The end of the input argument area shall be aligned on a 16 (32, if __m256 is passed on stack) byte boundary. – Caput
@GrzegorzSzpetkowski - i nothing know about Linux, but for processor view and Windows OS - 4 byte align for stack enouhg in 32bit – Doorjamb
@RbMm: You are are right about Windows. I should have specified the OS in question. – Caput
D
19

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 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.

Diamagnetic answered 30/10, 2016 at 1:53 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.