Ross Ridge writes:
> As I mentioned later in my message STACK_BOUNDARY shouldn't be defined in
> terms of hardware, but in terms of the ABI. While the i386 allows the
> stack pointer to bet set to any value, by convention the stack pointer
> is always kept 4-byte aligned at all times. GCC should never generate
> code that that would violate this requirement, even in leaf-functions
> or transitorily during the prologue/epilogue.
H.J. Lu writes:
> From gcc internal manual
I'm suggesting a different defintion of STACK_BOUNDARY which wouldn't,
if strictly followed, result STACK_BOUNDARY being defined as 8 on
the i386. The i386 hardware doesn't enforce a minimum alignment on the
stack pointer.
> Since x86 always push/pop stack by decrementing/incrementing address
> size, it makes senses to define STACK_BOUNDARY as address size.
The i386 PUSH and POP instructions adjust stack pointer the by the
operand size of the instruction. The address size of the instruction
has no effect. For example, GCC should never generate code like this:
pushw $0
pushw %ax
because the stack is temporarily misaligned. This could result in a
signal, trap, interrupt or other asynchronous handler using a misaligned
stack. In context of your proposal, defining STACK_BOUNDARY this way,
as a requirement imposed on GCC by an ABI (or at least by convention),
not the hardware, is important. Without an ABI requirement, there's
nothing that would prohibit an i386 leaf function from adjusting the
stack in a way that leaves the stack 1- or 2-byte aligned.
Ross Ridge
