Varargs issues

[Peter Wemm]

James Van Artsdalen wrote:

> The function prologue writes these floats to stack slots with the
> MOVAPS opcode.  The "AMD64 Architecture Programmer's Manual Volume 4:
> 128-Bit Media Instructions" manual states "A memory operand that is
> not aligned on a 16-byte boundary causes a general protection
> exception" for MOVAPS.
> 
> The trick is that gcc 3.3 doesn't seem to try to keep the stack
> aligned to 16-bytes, so on entry to a function the stack may be 8-byte
> aligned, 16-byte aligned, etc.  If the AMD book is not out-of-date
> then a fault is bound to happen on MOVAPS at some point.
> 
> This problem with this theory of course is that I'd expect a lot of
> crashes, more than are apparently being seen.  I don't have the
> documentation on the ABI calling conventions so I'm just guessing
> based on gcc's output (and I might not be using the right compiler).

gcc depends on the stack being correctly aligned at program entry and makes
sure it is aligned before making other function calls.  You'll see this in
subtle ways, eg: it'll reserve 32 bytes of stack space instead of the 24 that
it might actually use, etc.

If anything hoses the alignment, it all comes crashing down...  the movaps
stuff can and will blow up, as you point out.  Varargs is a very good litmus
test to see if the stack got misaligned somewhere since gcc does strange
stuff to pass the xmm registers.

Cheers,
-Peter
--
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5