https://bugs.winehq.org/show_bug.cgi?id=49698
Bug ID: 49698 Summary: Unwinding with a PE based ntdll.dll fails in some cases Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: martin@martin.st Distribution: ---
Created attachment 67943 --> https://bugs.winehq.org/attachment.cgi?id=67943 Testcase
If ntdll is built as a PE, some unwinding cases (that, as far as I understand, unwind through ntdll itself) fail, where the testcases succeed if wine is built with --without-mingw.
The attached testcase that fails is built from https://github.com/microsoft/compiler-tests/blob/master/eh/ehthrow.cxx with "cl ehthrow.cxx -Feehthrow-msvc-x64.exe -EHsc -O2" using MSVC 19.24.28314 for x64.
FWIW, in a non-PE build, this testcase also regressed earlier, in 887332f9c7bf0d75f53f88a9739b77b12463d636 "ntdll: Fix KiUserExceptionDispatcher ABI on x86_64.", but was fixed again by 12dba1b2ae50099de4cd857f867ebcaefe6852d8 "ntdll: Fix PE unwind info for %rsi, %rdi in KiUserExceptionDispatcher." I think.
https://bugs.winehq.org/show_bug.cgi?id=49698
Martin Storsjö martin@martin.st changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=49698
--- Comment #1 from Paul Gofman pgofman@codeweavers.com --- Thanks for bringing in handy test case.
I've tested the test.
The regression was triggered solely by ntdll switch to PE and does not interfere with any other patches.
The problem is in dlls/ntdll/signal_x86_64.c:call_consolidate_callback() function. It is supposed to return to the caller (RtlSetThreadContext) in case of normal return but in case if the callback unwinds (which is likely) the unwind should jump directly to the specified context and skip all the functions in between with their unwinds (that is the feature of consolidated unwind which does the unwind for multiple nested frames in one call). The required tricks were implemented with dwarf unwind info but not for PE unwinds, thus it was broken as soon as ntdll.dll is build as PE.
Patches [1], [2] are fixing the issue for me.
1. https://source.winehq.org/patches/data/190692 2. https://source.winehq.org/patches/data/190693
https://bugs.winehq.org/show_bug.cgi?id=49698
--- Comment #2 from Martin Storsjö martin@martin.st --- (In reply to Paul Gofman from comment #1)
Thanks for bringing in handy test case.
I've tested the test.
The regression was triggered solely by ntdll switch to PE and does not interfere with any other patches.
The problem is in dlls/ntdll/signal_x86_64.c:call_consolidate_callback() function. It is supposed to return to the caller (RtlSetThreadContext) in case of normal return but in case if the callback unwinds (which is likely) the unwind should jump directly to the specified context and skip all the functions in between with their unwinds (that is the feature of consolidated unwind which does the unwind for multiple nested frames in one call). The required tricks were implemented with dwarf unwind info but not for PE unwinds, thus it was broken as soon as ntdll.dll is build as PE.
Patches [1], [2] are fixing the issue for me.
Awesome, thanks! Yeah I had a suspicion that call_consolidate_callback was the culprit here (but I hadn't dug deep enough to actually verify it).
My reason for poking into it actually was that I was looking into fixing unwinding for a PE based ntdll for arm64, but I didn't have any good clue for how to handle call_consolidate_callback without the DWARF tricks, so I wanted to look into how the x86_64 implementation worked in PE/SEH mode.
So - now I can try to do something similar to that with the ARM64 variant of SEH. :-)
https://bugs.winehq.org/show_bug.cgi?id=49698
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox.xerox2000x@gmail.com
--- Comment #3 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Paul Gofman from comment #1)
Patches [1], [2] are fixing the issue for me.
I tried these two patches and these also fix bug 49508 for me, so i will resolve that one as duplicate Thanks Paul for the fix, hopefully committed in upcoming wine-5.15
https://bugs.winehq.org/show_bug.cgi?id=49698
--- Comment #4 from Louis Lenders xerox.xerox2000x@gmail.com --- *** Bug 49508 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=49698
--- Comment #5 from Paul Gofman pgofman@codeweavers.com --- Should be fixed by https://source.winehq.org/git/wine.git/commit/c76dc32feffaeed260bf73499e4301...
https://bugs.winehq.org/show_bug.cgi?id=49698
Martin Storsjö martin@martin.st changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |c76dc32feffaeed260bf73499e4 | |3012b69bee1b4 Resolution|--- |FIXED
--- Comment #6 from Martin Storsjö martin@martin.st --- This was already fixed a couple weeks ago, in c76dc32feffaeed260bf73499e43012b69bee1b4.
https://bugs.winehq.org/show_bug.cgi?id=49698
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.16.
-
WineHQ Bugzilla