Ross Ridge writes:
> This section doesn't make sense to me. The force_align_arg_pointer
> attribute and -mstackrealign assume that the ABI is being
> followed, while the -fpreferred-stack-boundary option effectively
"H.J. Lu" <hjl at lucon dot org> writes
> According to Apple engineer who implemented the -mstackrealign,
> on MacOS/ia32, psABI is 16byte, but -mstackrealign will assume
> 4byte, which is STACK_BOUNDARY.
Ok. The importanting thing is that for backwards compatibility it needs
to continue to assume 4-byte alignment on entry and align the stack to
a 16-byte alignment on x86 targets, so that makes more sense.
>> changes the ABI. According your defintions, I would think
>> that INCOMING should be ABI_STACK_BOUNDARY in the first case,
>> and MAX(ABI_STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) in the second.
>
> That isn't true since some .o files may not be compiled with
> -fpreferred-stack-boundary or with a different value of
> -fpreferred-stack-boundary.
Like with any ABI changing flag, that's not supported:
... Further, every function must be generated such that it keeps
the stack aligned. Thus calling a function compiled with a higher
preferred stack boundary from a function compiled with a lower
preferred stack boundary will most likely misalign the stack.
The -fpreferrred-stack-boundary flag currently generates code that
assumes the stack aligned to the preferred alignment on function entry.
If you assume a worse incoming alignment you'll be aligning the stack
unnecessarily and generating code that this flag doesn't require.
> On x86-64, ABI_STACK_BOUNDARY is 16byte, but the Linux kernel may
> want to use 8 byte for PREFERRED_STACK_BOUNDARY.
Ok, if people are using this flag to change the alignment to something
smaller than used by the standard ABI, then INCOMING should be
MAX(STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY).
Ross Ridge
