Date: Mon, 01 Dec 2003 14:36:40 -0800 From: Peter Wemm <peter@wemm.org> To: James Van Artsdalen <james-freebsd-amd64@jrv.org> Cc: freebsd-amd64@freebsd.org Subject: Re: Varargs issues Message-ID: <20031201223640.1A0C32A7EA@canning.wemm.org> In-Reply-To: <200312012208.hB1M8V1O064328@bigtex.jrv.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031201223640.1A0C32A7EA>