On Mon, Nov 12, 2012 at 09:25:57AM +0800, Dmitry Timoshkov wrote:
Maarten Lankhorst m.b.lankhorst@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