musl libc doesn't supply any definitions for IPX, such as the SOL_IPX
macro. However, it still provides linux/ipx.h from Linux uAPI header
files if it exists.
Linux kernel wouldn't drop linux/ipx.h from uAPI headers until 5.15,
although IPX support has already been marked obsolete since 2018.
Fix this by not defining HAS_IPX if linux/ipx.h has been included but
nothing defines the SOL_IPX macro.
Status of IPX support from other libcs are noted below:
- bionic: netipx/ipx.h does not exist. linux/ipx.h may or may not
exist. Note that sys/socket.h defines SOL_IPX even if linux/ipx.h is
missing.
- glibc: netipx/ipx.h exists. In this case, Wine assumes IPX support
even if the operating system does not support it in runtime.
- BSD variants: netipx/ipx.h may or may not exist. linux/ipx.h does not
exist. Some BSDs supply SO_DEFAULT_HEADERS instead of SOL_IPX.
Fixes: 954bf9e050
CFI directives allow the context that was stored on the stack by
raise_func_trampoline to be used to unwind to any exception handlers as
required when dispatching an exception. However, as the dispatcher may change
its input context in e.g. BTCpuResetToConsistentState and these changes also
need to be used when unwinding, have the trampoline CFI directly refer to the
input context rather than a copy of it.
Today, NtContinue() on ARM64 does not restore X16 and X17 from the
context.
This is because the values for X16 and X17 are overwritten when the
current thread returns to the "user mode" (PE side) via
__wine_syscall_dispatcher, which in turn uses them as scratch registers
for restoring SP and PC respectively.
We cannot avoid using scratch registers when restoring SP and PC. This
is because ARMv8 does not have an unprivileged (EL0) instruction that
loads SP and PC from memory or non-GPR architectural state.
Fix this by making ARM64 __wine_syscall_dispatcher perform a full
context restore via raise(SIGUSR2) when NtContinue() is used.
Since raising a signal is quite expensive, it should be done only when
necessary. To achieve this, split the ARM64 syscall dispatcher's
returning behaviour into a fast path (that does not involve signals) and
a slow path (that involves signals):
- If CONTEXT_INTEGER is not set, the dispatcher takes the fast path:
the X16 and X17 registers are clobbered as usual.
- If X16 == PC and X17 == SP, the dispatcher also takes the fast path:
it can safely use X16 and X17 without corrupting the register values,
since those two registers already have the desired values.
This fast path is used in call_user_apc_dispatcher(),
call_user_exception_dispatcher(), and call_init_thunk().
- Otherwise, the dispatcher takes the slow path: it raises SIGUSR2 and
does full context restore in the signal handler.
Fixes: 88e336214d
Many built-in callers of ActivateActCtx() just assume that it will
always succeed. If it ever fails, then DeactivateActCtx() will notice
that the cookie is invalid and raise an exception anyway.
When handling an exception, NtContinue can be called from within the signal
handler, in which case the raise(SIGUSR2) call ends up getting eaten and
integer register context never ends up getting restored. Switch to the
method used on X86 to avoid these issues.
4.18+ Linux kernels remove support for IPX but keep SOL_IPX defined, which
causes compilation errors as wine unconditionally uses IPX structures if
this is the case. Instead check for IPX_MTU to determine IPX support as it is
defined within the ipx.h header itself.
The FILE_DELETE_ON_CLOSE can be used with the FILE_DISPOSITION_ON_CLOSE flag
of FileDispositionInformationEx.
Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
Working around a Rosetta bug on Apple Silicon - faults for certain
instructions (e.g. lock cmpxchg8b) are misreported, which can break
VPROT_WRITEWATCH handling.
