10

In the prologue of the main function (of a simple toy program) that was compiled using gcc -g -o program -m32 program.c on a 64-bit machine (running ubuntu 14.04) I get the following disassembly:

dump of assembler code for function main:
   0x08048e24 <+0>: push   %ebp
   0x08048e25 <+1>: mov    %esp,%ebp
   0x08048e27 <+3>: and    $0xfffffff0,%esp
   ...

What's the purpose of the instruction at <+3>? That is, why should the $esp point to an 16-aligned address?

Bush
  • 2,433
  • 5
  • 34
  • 57

2 Answers2

10

The System V AMD64 ABI (x86-64 ABI) requires 16-byte stack alignment. double requires 8-byte alignment and SSE extensions require 16-byte alignment.

gcc documentation points it in its documentation for -mpreferred-stack-boundary option:

-mpreferred-stack-boundary=num

Attempt to keep the stack boundary aligned to a 2 raised to num byte boundary. If -mpreferred-stack-boundary is not specified, the default is 4 (16 bytes or 128 bits).

Warning: When generating code for the x86-64 architecture with SSE extensions disabled, -mpreferred-stack-boundary=3 can be used to keep the stack boundary aligned to 8 byte boundary. Since x86-64 ABI require 16 byte stack alignment, this is ABI incompatible and intended to be used in controlled environment where stack space is important limitation. This option leads to wrong code when functions compiled with 16 byte stack alignment (such as functions from a standard library) are called with misaligned stack. In this case, SSE instructions may lead to misaligned memory access traps. In addition, variable arguments are handled incorrectly for 16 byte aligned objects (including x87 long double and __int128), leading to wrong results. You must build all modules with -mpreferred-stack-boundary=3, including any libraries. This includes the system libraries and startup modules.

ouah
  • 142,963
  • 15
  • 272
  • 331
  • 1
    It still holds when I compile with -m32 flag? – Bush Nov 23 '15 at 11:29
  • @Bush I guess they use 16-byte with `-m32` also because of SSE. – ouah Nov 23 '15 at 11:38
  • Well, not every x86-64 ABI does that, so I am always a little irritated if people pretend there is only one and only x86-64 ABI. In this case, in the context of Ubuntu, it is clear which ABI is meant, but that is not always the case. – Rudy Velthuis Nov 23 '15 at 15:12
  • @RudyVelthuis it's a fair comment, I edited my answer to clarify we are talking about the System V AMD64 ABI – ouah Nov 23 '15 at 15:18
2

Modern versions of the i386 System V ABI have the same 16-byte stack alignment requirement / guarantee as x86-64 System V (which @ouah's answer mentions).

This includes a guarantee that the kernel will have aligned %esp by 16 at _start. So CRT startup code that also maintains 16-byte alignment will call main with the stack 16-byte aligned.

Historically, the i386 System V ABI only required 4-byte stack alignment, and aligning the stack by 16 was just something compilers could choose to do; GCC defaulted to -mpreferred-stack-boundary=4 when it was just a good idea, not the law (on MacOS and Linux).

Some BSD versions I think still don't require 16-byte stack alignment in 32-bit code, so 32-bit code that want to use aligned memory for a double, int64_t, or especially an XMM vector, does need to manually align the stack instead of relying on incoming stack alignment.

But even on modern Linux, GCC's 32-bit-mode (-m32) behaviour for main doesn't assume that main's caller (or the kernel) follows the ABI, and manually aligns the stack.

See Responsibility of stack alignment in 32-bit x86 assembly for more; another question where the obsolete instruction led to confusion based on the assumption that it was needed.

GCC on x86-64 does not do this, and does just take advantage of the fact that 16-byte stack alignment has always been a requirement in the x86-64 System V ABI. (And the Windows x64 ABI).

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847