https://bugs.winehq.org/show_bug.cgi?id=55470
Bug ID: 55470 Summary: i686-w64-mingw32-gcc assumes wrong stack alignment Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs@winehq.org Reporter: stefan@codeweavers.com Distribution: ---
Created attachment 75028 --> https://bugs.winehq.org/attachment.cgi?id=75028 Example C code to show the issue
This is probably not a Wine bug, but something we may want to document and take care of one way or another:
i686-w64-mingw32-gcc quietly assumes 16 byte stack alignment, which is wrong for Win32. To see the effect compile and disassemble the attached test.c with
i686-w64-mingw32-gcc test.c -c -O2 i686-w64-mingw32-objdump -d test.o
The outcome: 0: 81 ec ac 01 00 00 sub $0x1ac,%esp 6: 8d 44 24 10 lea 0x10(%esp),%eax a: 89 04 24 mov %eax,(%esp) d: e8 00 00 00 00 call 12 <_func+0x12> 12: 81 c4 ac 01 00 00 add $0x1ac,%esp 18: c3 ret
However, x86_64-w64-mingw32-gcc -m32 properly aligns the stack before placing the aligned structure:
x86_64-w64-mingw32-gcc test.c -c -O2 -m32 i686-w64-mingw32-objdump -d test.o 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 83 e4 f0 and $0xfffffff0,%esp 6: 81 ec a0 01 00 00 sub $0x1a0,%esp c: 8d 44 24 10 lea 0x10(%esp),%eax 10: 89 04 24 mov %eax,(%esp) 13: e8 00 00 00 00 call 18 <_func+0x18> 18: c9 leave 19: c3 ret
To my knowledge Wine does not use SSE instructions on purpose, so we should be mostly fine. msvcrt, wined3d or dsound (especially when compiled to use SSE to make Rosetta 2 happy) may be affected.
The test.c file is attached.
What can we do about it?
1) Ignore it 2) pass -mincoming-stack-boundary=2 to mingw for 32 bit targets 3) Use 64 bit target mingw with -m32
I'll file a bug for mingw too, linking this bug as reference.
https://bugs.winehq.org/show_bug.cgi?id=55470
--- Comment #1 from Stefan Dösinger stefan@codeweavers.com --- I have filed https://github.com/mingw-w64/mingw-w64/issues/30 , but I don't know if this is the correct place to report mingw-w64 bugs. https://www.mingw-w64.org/ points to this github repo, but it says "(Unofficial) Mirror of mingw-w64-code".
https://bugs.winehq.org/show_bug.cgi?id=55470
--- Comment #2 from Stefan Dösinger stefan@codeweavers.com --- Building 32 bit libs with x86_64-w64-mingw32-gcc -m32 is not really an option. It breaks in a lot of ways just linking a hello world program. It is apparently not meant to be used in this way.
https://bugs.winehq.org/show_bug.cgi?id=55470
--- Comment #3 from Stefan Dösinger stefan@codeweavers.com --- Interestingly building x86 code with -march=core2 (or anything starting from -march=pentium3) causes mingw to align the stack.
https://bugs.winehq.org/show_bug.cgi?id=55470
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- This sounds a bit like bug 55007, but its upstream counterpart (gcc110273) had been quiet for roughly the last two months.
https://bugs.winehq.org/show_bug.cgi?id=55470
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #5 from Zeb Figura z.figura12@gmail.com --- (In reply to Rafał Mużyło from comment #4)
This sounds a bit like bug 55007, but its upstream counterpart (gcc110273) had been quiet for roughly the last two months.
Bug 55007 is specific to SSE instruction generation, 13.x, and -march=znver4. This is specific to __attribute__ ((aligned)), it doesn't involve SSE instructions, and it doesn't require -march to produce.
https://bugs.winehq.org/show_bug.cgi?id=55470
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- ...hmm, how about my bug 52676 ?
I don't really understand that asm comment from Fabian. Any chance that was related ?
https://bugs.winehq.org/show_bug.cgi?id=55470
--- Comment #7 from Stefan Dösinger stefan@codeweavers.com --- There are a lot of compiler alignment related bugs. I am not opposed to closing this one (or others) as duplicates. How the compiler ends up generating alignment dependent code (either by explicit request like in my C sample or via SSE) is I think less important than that gcc uses the wrong defaults when targeting x86 Windows.
One thing I noticed in my investigation is that -march=pentium3 (or newer, though apparently not znver4) makes the compiler realign the stack in my example. I looked into this because I know Crossover's 32 bit DLLs are built with -mfpmath=sse -march=core2. The SSE instructions generated by this happen to work because of that -march argument.
Note that just having an SSE instruction doesn't mean the code crashes when the stack is misaligned - if e.g. a function only runs SSE operations on data passed in as function arguments it won't care about the stack alignment.
https://bugs.winehq.org/show_bug.cgi?id=55470
--- Comment #8 from Zeb Figura z.figura12@gmail.com --- (In reply to Stefan Dösinger from comment #7)
There are a lot of compiler alignment related bugs. I am not opposed to closing this one (or others) as duplicates. How the compiler ends up generating alignment dependent code (either by explicit request like in my C sample or via SSE) is I think less important than that gcc uses the wrong defaults when targeting x86 Windows.
Well, the critical point is that it doesn't, though; gcc *does* in general agree that i386-w64-mingw has a stack alignment of 4. You can see this when it generates SSE instructions (except for the conditions of bug 55007). But for some reason that doesn't apply to manually aligned types.
https://bugs.winehq.org/show_bug.cgi?id=55470
Gabriel Ravier gabravier@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabravier@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=55470
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #9 from Bernhard Übelacker bernhardu@mailbox.org --- Following commit adds "-mpreferred-stack-boundary=2" instead of "-mincoming-stack-boundary=2". Is this enough for this bug?
https://gitlab.winehq.org/wine/wine/-/commit/4b458775bb8c9492ac859cfd167c5f5...