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