If the handlers returned ExceptionContinueExecution and we restore
the stored context, make sure it's a context that ends up returning
from the RtlRaiseException function.
This matches how it's done on x86_64.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some language specific handlers, called by call_handler, can use
the NonVolatileRegisters to restore the context before running
code, and that assumes that NonVolatileRegisters contains the frame
pointer as it was within the function (before unwinding).
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Call the consolidate frame callback before resuming. Before
calling the callback, fill in ExceptionInformation[10] with the
equivalent of dispatch.NonVolatileRegisters.
This fixes unwinding of MSVC C++ exceptions in a lot of cases.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This happens with functions that aren't intended to return e.g. like
_Unwind_Resume. In these cases, the return address is outside of the
function (the first instruction in the next function).
Set the flag CONTEXT_UNWOUND_TO_CALL after unwinding to a callsite,
and if this flag is set, look up a RUNTIME_FUNCTION based on
Control.Pc - 4.
This isn't a complete (nor probably entirely correct) implementation
of the flag CONTEXT_UNWOUND_TO_CALL, but it practically seems to
work fine and fixes a large number of unwinding cases.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In most cases, unwinding will use the frame pointer anyway, so it
doesn't make much of a difference, but for cases where it won't,
capture the actual stack pointer.
(In most cases on arm64, calling the RtlCaptureContext won't cause
anything extra to be pushed on the stack at that point anyway).
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This matches what was done for RtlUnwindEx in
93ecc54ae5, applying the same change
in call_function_handlers (when called from raise_exception).
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
restore_regs and restore_fpregs take offsets in units of registers,
not bytes.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The register offset should be multiplied by 2, and the second
register is always Lr.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For the CR == 3 case, x29/x30 should be restored from x29, not from
sp, which may have been decremented further for local stack storage.
This fixes uwinding the stack for C++ exceptions in code generated
by MSVC.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes crashes when handling GNU/mingw style SEH based C++
exceptions on arm64; in these cases unwind_full_data ended up
where it tries to write handler_rva + 1 to *handler_data.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The previous implementation might have given the impression of
working, as long in some cases where the PE code actually used frame
pointers, but turned out to be subly wrong.
This essentially reverts the functional aspects of 1c9fdaab0f.
Use the new value of the Lr register, after fetching the registers
from unw_step, as the return value.
To make single-stepping unwinding work properly, treat the registers
consistently:
- Make RtlCaptureContext store the current values of x29/Fp and x30/Lr
from within the function, not the ones backed up from the stack.
- After unwinding one step, first fetch the new values of all registers,
including the new value of Lr - then use this value of Lr to set the
new value of Pc (the address to actually return to).
This makes the unwinding actually coherent in reading unwind opcodes and
return addresses from one single function; previously these were out of
sync where the return address ended up being read from the function
one step further up in the call stack.
This fixes unwinding for setjmp for binaries compiled with clang
(in mingw mode).
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This name is used in Microsoft's public winternl.h.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If libunwind is unavailable, make libunwind_virtual_unwind return an
error. Likewise if there was no PE exception info and we didn't try
unwinding using libunwind, we need to return an error when realizing
we were unable to unwind, instead of just warning and returning
success.
This fixes hangs/infinite loops on crashes when unwinding fails.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: André Hentschel <nerv@dawncrow.de>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Alexandre Julliard