http://bugs.winehq.org/show_bug.cgi?id=22316
Summary: Wine should be built with -mincoming-stack-boundary=2 Product: Wine Version: 1.1.42 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: build-env AssignedTo: wine-bugs@winehq.org ReportedBy: daniel-gl@gmx.net
GCC 4.4 on Linux assumes the Stack is aligned to 16 bytes and thus assumes it can use the movdqa instruction when manipulating 64 bit values on the stack. For x86-32 Windows Microsoft specifies a stack alignment of 4 Bytes.
In my case I had wine compiled with -O3 -march=native and got an "Unhandled page fault on read access to 0xffffffff" with the disassembly showing "movq %mm5,%mm3" as the faulting instruction. Running objdump revealed the instruction was in fact "movdqa %xmm3,-0x88(%ebp)" while ebp % 16 had been 4 since the app entered wine code.
Therefore I propose to compile wine with -mincoming-stack-boundary=2 where it is available.
http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2010-04-09 05:18:22 --- That's a gcc bug, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838. The Linux de-facto ABI is 4-byte alignment.
http://bugs.winehq.org/show_bug.cgi?id=22316
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2010-04-09 05:49:06 --- Invalid then.
http://bugs.winehq.org/show_bug.cgi?id=22316
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #3 from Dmitry Timoshkov dmitry@codeweavers.com 2010-04-09 05:49:19 --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=22316
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |t.artem@mailcity.com
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2010-04-17 04:53:21 --- *** Bug 22385 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2010-04-17 08:52:36 --- *** Bug 22387 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22316
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sandalle@sourcemage.org
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2010-04-26 00:51:43 --- *** Bug 22475 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22316
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #7 from Dan Kegel dank@kegel.com 2010-11-07 07:02:01 CST --- Daniel, does gcc-4.5.1 behave better?
http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #8 from Artem S. Tashkinov t.artem@mailcity.com 2010-11-07 08:01:26 CST --- Let me have the insolence to say on Daniel's behalf that GCC 4.5.1 is no different to GCC 4.4 in the regard.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 has zero activity, it's not even on GCC developers radar (bug status: unassigned). GCC 4.6.0 will most likely have the same problem.
http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #9 from Dan Kegel dank@kegel.com 2010-11-07 08:05:45 CST --- Does the option -mstackrealign help? From that bug report, and from Artem's response on bug 22387, I gather that might be the thing to do when using aggressive optimizations on gcc-4.5.x.
http://bugs.winehq.org/show_bug.cgi?id=22316
Mike Frysinger vapier@gentoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vapier@gentoo.org
--- Comment #10 from Mike Frysinger vapier@gentoo.org 2011-07-12 01:09:23 CDT --- i'm not sure punting this to gcc works anymore. the Linux x86 ABI requires 16 bytes, so any random Windows programs that unalign below that will cause problems in code that assumes 16 byte alignment.
ive got at least 2 reports of -mstackrealign fixing things for people.
http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2011-07-12 03:31:46 CDT --- (In reply to comment #10)
i'm not sure punting this to gcc works anymore. the Linux x86 ABI requires 16 bytes, so any random Windows programs that unalign below that will cause problems in code that assumes 16 byte alignment.
The Linux ABI has never required 16 bytes, except maybe on paper. The fact is that there are many apps out there, Wine among them, that don't align to 16 bytes. Even if Wine starts forcing alignment today, there's nothing we can do about all the existing binaries. I don't understand how it can be considered acceptable to break backwards compatibility that way.
http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #12 from Mike Frysinger vapier@gentoo.org 2011-07-12 11:03:34 CDT --- so even though the standard says "stack must be 16byte aligned", and gcc assumes the stack is 16byte aligned and will generate code that requires that (i.e. sse), you still don't care if wine breaks (as reported by various distros/users) ?
existing apps dont matter ... their stack isnt passed in. it's created fresh upon execution, so the change in ABI is irrelevant to them. if they work with 4byte alignment, and they only use 4byte alignment, then starting off with 16byte alignment changes nothing.
what matters here are newly compiled programs as that is where the code generation is coming from.
http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #13 from Dan Kegel dank@kegel.com 2011-07-12 11:11:11 CDT --- The standard says 4 bytes. gcc deviates intentionally from the standard because current ia32 works better with 8 or 16 byte alignment.
I filed http://bugs.linuxbase.org/show_bug.cgi?id=3268 about the problem, let's see what they say.
http://bugs.winehq.org/show_bug.cgi?id=22316
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #14 from Mike Frysinger vapier@gentoo.org 2011-07-12 14:01:10 CDT --- the gcc PR mentioned in comment #1 says the Linux ABI is (being updated to say?) 16 bytes. the man page also indicates that 4 byte is legacy and 16 byte is modern. and further, the man page says that it realigns the stack only when needed. so i dont understand why this would be unacceptable to the wine devs as it doesnt affect code output if no SSE code is generated that needs 16byte alignment.
-mstackrealign Realign the stack at entry. On the Intel x86, the -mstackrealign option will generate an alternate prologue and epilogue that realigns the runtime stack if necessary. This supports mixing legacy codes that keep a 4-byte aligned stack with modern codes that keep a 16-byte stack for SSE compatibility. See also the attribute "force_align_arg_pointer", applicable to individual functions.
http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2011-07-12 14:57:30 CDT --- (In reply to comment #14)
the gcc PR mentioned in comment #1 says the Linux ABI is (being updated to say?) 16 bytes. the man page also indicates that 4 byte is legacy and 16 byte is modern. and further, the man page says that it realigns the stack only when needed. so i dont understand why this would be unacceptable to the wine devs as it doesnt affect code output if no SSE code is generated that needs 16byte alignment.
-mstackrealign Realign the stack at entry. On the Intel x86, the -mstackrealign option will generate an alternate prologue and epilogue that realigns the runtime stack if necessary. This supports mixing legacy codes that keep a 4-byte aligned stack with modern codes that keep a 16-byte stack for SSE compatibility. See also the attribute "force_align_arg_pointer", applicable to individual functions.
This always aligns the stack. It's what we use on the Mac, where the ABI truly is 16 bytes. It has a significant performance cost since it has to be done on every entry point.
It can certainly be used by people who want to build Wine with aggressive optimization, though the cost of the constant realignments would probably wipe out any benefits from the extra optimizations. It's not something we want to do by default if it can be avoided.
The real problem however is gcc causing new alignment requirements to sneak into system libraries. That's what breaks compatibility, and the only solution is for gcc to default to backwards-compatible behavior, and require an explicit option for the new ABI. That's what that gcc bug is about.
http://bugs.winehq.org/show_bug.cgi?id=22316
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xvachon@gmail.com
--- Comment #16 from Andrew Eikum aeikum@codeweavers.com 2012-02-06 10:56:17 CST --- *** Bug 29431 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22316
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr
http://bugs.winehq.org/show_bug.cgi?id=22316
cxcxcxcx@gmail.com cxcxcxcx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cxcxcxcx@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=22316
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stevenvandenbrandenstift@gm | |ail.com
--- Comment #17 from Austin English austinenglish@gmail.com 2012-07-31 17:45:26 CDT --- *** Bug 31375 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22316
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tiago_tagliaferri@msn.com
--- Comment #18 from Austin English austinenglish@gmail.com 2012-08-01 17:35:47 CDT --- *** Bug 31379 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22316
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hugo@osvaldobarrera.com.ar
--- Comment #19 from Dan Kegel dank@kegel.com 2012-08-11 09:13:03 CDT --- *** Bug 31444 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22316
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://gcc.gnu.org/bugzilla | |/show_bug.cgi?id=40838 Resolution|INVALID |UPSTREAM
http://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #20 from Dan Kegel dank@kegel.com 2013-06-15 10:09:50 CDT --- https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3268 is now marked P1 blocker, for what it's worth, but I bet it will be resolved by defining 16 byte alignment as the standard, since the LSB is mostly about codifying existing practice.
http://bugs.winehq.org/show_bug.cgi?id=22316
Anssi Hannula anssi@mageia.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anssi@mageia.org
https://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #21 from Jerome Leclanche adys.wh@gmail.com --- Was this fixed upstream? If it's not fixed upstream this bug shouldn't be CLOSED yet.
https://bugs.winehq.org/show_bug.cgi?id=22316
--- Comment #22 from Anssi Hannula anssi@mageia.org --- I don't think this was fixed upstream, but this workaround was applied to wine: http://source.winehq.org/git/wine.git/commitdiff/4adfb787f4e8c36a37ce1d53a7e...