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>
dlinfo() doesn't conform to a standard, each platform implements in differently,
if at all. On GNU and NetBSD its l_addr field returned is the "relocbase",
the relative offset between addresses wanted by the file and addresses obtained
in memory (==0 when no relocation occurred), which we add to d_un.d_ptr to
obtain the memory address where the initializer is. On FreeBSD (and possibly
Solaris) this won't work, as l_addr is the "mapbase" instead, the absolute
starting memory address where the binary was loaded, resulting in wrong
calculations and crashes on startup as we call into wrong addresses.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49139
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
An extra byte for a null-terminator was added for every string, but not
used when the string was empty. This resulted in extra bytes at the end
of the buffer, causing parse errors in dmidecode.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The USD page is created when the first process (wineboot.exe) completes
its creation, using its provided user_shared_data for initialization.
The server maps the page write-only and the clients map it read-only,
then the server updates the timestamps every 16 ms.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=29168
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Alexandre Julliard