[PATCH 5/8] ntdll: Add detection for PF_SSE_DAZ_MODE_AVAILABLE

[David Laight]

On Sun, Oct 21, 2012 at 04:16:04PM -0600, James Eder wrote:
> Hmmm... the GCC docs say:
> 
> http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Type-Attributes.html#Type-Attributes
> 
> "Note that the alignment of any given struct or union type is required
> by the ISO C standard to be at least a perfect multiple of the lowest
> common multiple of the alignments of all of the members of the struct
> or union in question. This means that you can effectively adjust the
> alignment of a struct or union type by attaching an aligned attribute
> to any one of the members of such a type, [...]"
> 
> So, with conforming compilers, the having M128A aligned makes
> XMM_SAVE_AREA32 aligned. I tried it out some and I wasn't able to find
> a case which GCC (4.7.2) didn't align XMM_SAVE_AREA32 at 16 with M128A
> declared the way it is.

With the default gcc configuration and parameters used on Linux, 128 bit
(16 byte) alignment of on-stack items assumes that the stack is 16 byte
aligned.

While the code generated by gcc for function calls maintains this
alignement, it isn't part of the standard ABI and other code may not
do so.
If you read up on this you'll find someone tried detecting misaligned
stacks and found they happened all the time.
Pertinent to wine is that code compiled with MSC will not maintain that
alignment, any assembler wrappers are unlikely to as well.

There are some options to gcc that affect the generated code, one will
force the stack to be realigned if any locals need 16 byte alignement.
Changing some of the other options will cause internal compiler faults!

The code in gcc is made more complicated by the fact that it is useful
to align 8 byte items, but never (AFAICT) necessary to do so, and gcc
tries to align on-stack double and long-long items but not realign the
stack in order to do so.

We've just gone through a series of hoops in NetBSD trying to fix
gcc to generate code that doesn't assume 16 byte aligned stack and
doesn't fault internally.

	David

-- 
David Laight: david at l8s.co.uk