Commit f37b953e07 (ntdll: Support both HP-UX-like libunwind and LLVM
libunwind error codes., 2021-12-10) made an unsuccessful attempt to fix
UNW_ENOINFO detection on LLVM libunwind. It turns out that UNW_ENOINFO
is actually negative in LLVM, so there's no need to flip the sign.
Fix this by flipping the return value sign only when UNW_ENOINFO < 0
(LLVM libunwind), and then comparing it against the negated error code.
Overall, all flavours of libunwind return a negative value on error.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
HP-UX libunwind uses the sign of error code to indicate whether the
operation was successful; however, LLVM always returns positive error
codes.
Normalise the sign of the error code so that it handles all flavours of
libunwind.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes unwinding from functions ending with a call to a function
that won't return. This matches what is done on the PE side in the
call to lookup_function_info.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In PE builds of wine, there's no unwind info (as LLVM hasn't
implemented generating SEH unwind info for ARM yet).
On startup of wine, an exception of the type RPC_S_SERVER_UNAVAILABLE
is raised. In a PE build of Wine, the unwind would get stuck in
an infinite loop.
This still loops for a short while; after returning the error
STATUS_INVALID_DISPOSITION, KiUserExceptionDispatcher ends up
calling RtlRaiseStatus with this status, which then tries to
unwind again, getting stuck similarly. However by recursively
trying to unwind multiple times, the process crashes fairly soon
after running out of stack.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is a very close copy of the arm64 implementation.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Store the original stack pointer (on entry to the syscall dispatcher)
in syscall_frame; the stack pointer itself is incremented by
"pop {r0-r3}" right before calling the syscall itself.
This fixes unwinding from functions set up by syscalls, like
KiUserExceptionDispatcher.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This does the same as 23b44e8df6,
but for arm:
Don't call KiUserExceptionDispatcher directly on the stack pointer
stored in the CONTEXT, but use the one stored in syscall_frame
(which includes the stack allocation in e.g. RtlRaiseException).
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This reverts commit 8b8ddffa21.
ws2_32 no longer uses system APCs.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The frame can currently be reset from ws2_32.dll async IO callbacks
which are still in the user part and are calling 'syscall' functions.
If the user APC is processed after that during the same call to
server_select(), the call_user_apc_dispatcher() faults.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49782
Signed-off-by: Paul Gofman <pgofman@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Jinoh Kang