ABI voilation

Tim Prince tprince@computer.org
Wed Oct 10 13:23:00 GMT 2007


Andrew Haley wrote:
> Ian Lance Taylor writes:
>  > Andrew Haley <aph-gcc@littlepinkcloud.COM> writes:
>  > 
>  > > Geer Bosch asked "Can't we just explicitly align the stack frame to
>  > > 128-bits during the function prologue, when we know that there are
>  > > locals that require such alignment?"  This seems so obvious that I
>  > > can't understand why it hasn't been done.
>  > 
>  > If you don't trust your startup code, use -mstackrealign or the
>  > force_align_arg_pointer function attribute.
>  > 
>  > We don't do it by default because it is slower and most people don't
>  > need it.
> 
> This doesn't make any sense to me.  From what people have been saying
> here, using -Os *dealigns* the stack pointer, causing programs using
> SSE etc to fail.  Do we seriously want this to happen?  Is -Os
> supposed silently to break programs?
> 
In 32-bit mode, situations have been alleged where the reduced stack
alignment of -Os necessary to fit applications with huge call stacks.
malloc() for 32-bit linux usually is 8 byte aligned, (4-byte aligned for
Windows) so there is another source of difficulty in maintaining greater
alignment.  Due to inconsistent stack alignments, it is not safe to call
a gcc function which uses parallel SSE from a 32-bit Intel compiled
function.
In 64-bit mode, problem with hard stack size limit seems unlikely, and
even Windows ABI specifies 16-byte alignments.  We do run into
situations where larger than default thread stack size has to be
specified, but reduced alignment should not normally be considered.
Intel compiler option -Os doesn't tinker with stack alignment.



More information about the Gcc-help mailing list