And add tests to show that the address is always zeroed out even if
there is an error, and that WSAStringToAddress has the same bug with
leading double colons as RtlIpv6StringToAddress.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Currently, there is a race condition where if two threads call into
OpenGL at the same time, one of them will initialize OpenGL, but the
other will barrel on ahead, thinking GL is already initialized, even
though the first thread hasn't finished initializing it yet. One of the
symptoms of this is that no pixel formats appear to be available,
because the first thread hasn't yet enumerated the available pixel
formats.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of in wined3d_context_vk_load_shader_resources(). Loading resources
can end up flushing the current command buffer. There's also no reason to
reference the same resource multiple times by the same command buffer.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Current output is stored as part of the swapchain state now.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
dxgi_swapchain_set_fullscreen_state() is a mere wrapper of
wined3d_swapchain_state_set_fullscreen() now.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
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>
Those are available in UCRT (MSVC since 2015) and cause redefinition
warnings if math.h is included after test.h.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
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>
Alex Henrie