[Bug 55470] New: i686-w64-mingw32-gcc assumes wrong stack alignment
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(a)winehq.org Reporter: stefan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55470 --- Comment #1 from Stefan Dösinger <stefan(a)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". -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55470 --- Comment #2 from Stefan Dösinger <stefan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55470 --- Comment #3 from Stefan Dösinger <stefan(a)codeweavers.com> --- Interestingly building x86 code with -march=core2 (or anything starting from -march=pentium3) causes mingw to align the stack. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55470 --- Comment #4 from Rafał Mużyło <galtgendo(a)o2.pl> --- This sounds a bit like bug 55007, but its upstream counterpart (gcc110273) had been quiet for roughly the last two months. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55470 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #5 from Zeb Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55470 --- Comment #6 from Rafał Mużyło <galtgendo(a)o2.pl> --- ...hmm, how about my bug 52676 ? I don't really understand that asm comment from Fabian. Any chance that was related ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55470 --- Comment #7 from Stefan Dösinger <stefan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55470 --- Comment #8 from Zeb Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55470 Gabriel Ravier <gabravier(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gabravier(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55470 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org --- Comment #9 from Bernhard Übelacker <bernhardu(a)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... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla