This implements the general fix from
b1a79c6b9c (in particular, making sure
that Sleep(0) will not immediately resume execution of the thread if
there are no other runnable threads) while preserving the existing
behavior of NtYieldExecution() / SwitchToThread(). Thanks Rémi for the
idea.
Signed-off-by: Matteo Bruni <mbruni@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rémi found a regression caused by that patch. His analysis suggests
that it's probably correct for NtYieldExecution() to map to
sched_yield().
Let's revert the patch and fix the issue in a slightly different way.
This reverts commit b1a79c6b9c.
Signed-off-by: Matteo Bruni <mbruni@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In particular, if import_dll() skips an unused import, it will return TRUE,
but set *pwm to NULL. This fixes a regression in 3DMark03 version 3.4.0,
introduced by commit 0dd37b02f9.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
These will be used to implement RtlWaitOnAddress() and other in-process
synchronization primitives, as they are on Windows.
These patches went through quite a few revisions in order to ensure that they
had sufficient performance and correctness compared to the current
implementation. I am particularly grateful to Etienne Juvigny and Dmitry
Skvortsov for performing extensive testing.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.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>
We ideally should back up all of d0-d31, but when building in ELF
form, only d0-d15 are normally available (with common distributions'
default compilers), unless object files are built with flags to enable
support for d16-d31 (with e.g. -mfpu=neon).
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
RtlCaptureContext doesn't set context->Lr, which is needed for
being able to unwind from the context.
This matches what is done in the arm64 version.
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 doesn't fix (or break) any case known to me, but the code seems
wrong.
Leaf functions on arm (either 32 or 64) don't generally have any
default/implicit stack allocation.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Matteo Bruni