This mirrors ae07938ba6 (from x86_64)
to arm64.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This applies the beahviour from a69762541a
(on x86_64) to arm64 as well.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Try to keep the behaviour from ea9f47a767 of erroring out if
unwinding ends up out of bounds (with pc==lr, where setting pc
to lr doesn't progress the unwind), but support unwinding from
functions without unwind info.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Make sure to restore sp from fp for CR == 3.
Fix unwinding of partial prologues/epilogues - the previous logic
had an off-by-one for the pos/skip handling; fix a few more
corner cases with odd number of saved registers.
Functions with the H flag set (saving x0-x7 on the stack) should
be considred having 4 nops (for the instructions saving the
registers) in the prologue for unwind purposes. When unwinding
through a partial epilogue, the same 4 nops should also be
considered to be there (even though no sane epilogue would restore
the registers there) based on how windows handles partial epilogue
unwinding in those cases.
Uncomment prologue/epilogue cases in an existing test and add
tests for many more cases.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes unwinding through RtlRaiseException and
call_consolidate_callback in PE builds.
Adjust the call_consolidate_callback function to store the whole
context on the stack, and use the seh "context" opcode for
unwinding to that context instead of the parent. Adjust the dwarf
escape codes for reading from the context on the stack.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Since 5b3842451b we set the flag indicating that the context
contained float registers, but we didn't actually populate them yet.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fix a typo in copying fields from the jump buffer to the context,
use the right type of long in the struct.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This matches what tests show is done on actual windows, in the
current testcases; in all currently tested cases, handler_data is
reset to NULL when no handler is returned.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
CONTEXT_FLOATING_POINT should be included in CONTEXT_FULL, and
there's a new flag CONTEXT_ARM64_X18 (not available without
the arch specific prefix) that only is part of CONTEXT_ALL.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
CoD: Black Ops 3 and CoD: WWII modify these (and several others) and
expect to have enough space for a few instructions.
It then verifies later that the patches are still in place, and
terminates if the byte sequence do not match. Having small symbols can
make the patches to overlap and the check to fail.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
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>
Jacek Caban