- 18 Jul, 2023 4 commits
-
-
Brendan Shanks authored
This is needed to be a correct macOS 10.7 binary.
-
Brendan Shanks authored
A zerofill section is the only way to reserve address space and prevent system frameworks from using it, including preventing allocations before any preloader code runs: - starting with Ventura, dyld allocates private memory from 0x1000-0x81000. This breaks EXEs that have an image base of 0x10000. - Rosetta allocates memory starting at 0x100000000, which breaks EXEs based there. - starting with Monterey, for proper 10.7 binaries (which include a __program_vars section), libSystem initializes itself before the preloader runs. This fragments the <4GB address space which is needed for Wow64. This will need to be adjusted if any EXEs based at 0x200000000 or higher are found.
-
Brendan Shanks authored
-
Brendan Shanks authored
-
- 17 Jul, 2023 34 commits
-
-
Biswapriyo Nath authored
-
Jeff Smith authored
-
Jacek Caban authored
-
Jacek Caban authored
-
Jacek Caban authored
-
Jacek Caban authored
-
Jacek Caban authored
-
Jacek Caban authored
-
Zhao Yi authored
Signed-off-by: Zhaoyi <zhaoyi@uniontech.com>
-
Zhao Yi authored
Signed-off-by: Zhaoyi <zhaoyi@uniontech.com>
-
Shaun Ren authored
-
Shaun Ren authored
-
Shaun Ren authored
-
Shaun Ren authored
-
Jacob Czekalla authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Victor Chiletto authored
re4_tweaks relies on this function being hotpatchable [1]. [1]: https://github.com/nipkownix/re4_tweaks/blob/7cfcf5c4272f7d68d177661ffe84e9d1e0d2f383/dllmain/input.cpp#L903
-
Jinoh Kang authored
SafeSEH is not applicable to architectures other than i386. This fixes compiling with the clang ARM assembler, which cannot parse ".def @feat.00" since "@" is parsed as the start of a line comment.
-
Jinoh Kang authored
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: 88e33621
-
Nikolay Sivov authored
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
-
Alistair Leslie-Hughes authored
-
Alistair Leslie-Hughes authored
-
Bernhard Kölbl authored
-
Bernhard Kölbl authored
-
- 14 Jul, 2023 2 commits