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