[PATCH] includes: always add __force_align_arg_pointer__ for i386

[David Laight]

On Mon, Nov 12, 2012 at 09:25:57AM +0800, Dmitry Timoshkov wrote:
> Maarten Lankhorst <m.b.lankhorst at gmail.com> wrote:
> 
> > Fixes flstudio installer on my system, which breaks otherwise in strcasestr_sse42_nonascii
> > due to stack being misaligned.
> 
> That's a compiler bug: http://bugs.winehq.org/show_bug.cgi?id=22316

Having recently gone around that gcc 'feature loop' for NetBSD (NetBSD
6 (just released) has gcc build to only assume/maintain 4 byte stack
alignment), but not having looked at strcasestr_sse42_nonascii() itself!

There is thread on some linux mailing listA about issues with the
assumption of 16 byte stack alignment, and someone trying to run code
where the compielr had been patched to generate a prologue that generated
an error message if stack frames were misaligned - it happened a lot
even on with code only compiled by gcc (probably due to asm stubs and
old code/code compiled with different options).

We discovered that -mstackalign eventualy got fixed to align stacks of
functions that save 16byte aligned items on stack (used %bp to access
parameters and %sp to locals - horrid if alloca() also used).

If you tell gcc the stack is only 4 byte aligned, gcc will generate
some internal consistency errors unless some other patches are made.
Maintaining 8 byte alignment should be ok.

If you only set -mstackalign then the default alignment is assumed
valid for items requesting 8-byte alignment. This is done becase it
is useful to align double and long long - but the cpu won't fault
on any misaligned accesses to 8-byte items.

I'm not sure anyone has actually done any measurements that account
for the increased cache usage of the 16 byte aligning the stack against
the gain for not having to align it for the rare functions that
actually need 16 byte alignment.

Intereseting, maintaining 8 byte alignment - so that double can be
chaply aligned - may be more useful!

NetBSD found issues with 'normal' code that, when compiled with
suitable options, would try to save SSE2 registers on stack (loop
got vectorised by the compiler).

>From a wine point of view, any code that calls into libc (or similar)
and might have come from microsoft code probably has to align the stack
(set the incoming stack alignment - possibly as an attribute).
Functions that don't call out of wine can just set -mstackrealign in case
they happen to use SSE2 instrctions.

It is all a pig's breakfast.

	David

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