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.
On Apple Silicon, Rosetta allocates memory starting at 0x100000000
(the 4GB line) before the preloader runs.
The .NET 3.5 installer and DirectX Jun2010 redistributable both contain
non-relocatable EXEs with that base address, which fail to run.
The workaround is to create an empty linker section at that address,
which is mapped by the kernel before Rosetta runs and forces Rosetta's
allocations higher in memory.
The linker section runs from 0x100000000-0x114000000.
Rosetta's allocations are ~132MB, and should end below 0x120000000.
This is not an exact science: a non-relocatable EXE with base address
between 0x114000000-0x120000000 will fail to run. If one is discovered,
the section size will need to be changed.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
On Apple Silicon, Rosetta's shared cache starts at 0x7ffe00000000 and
the runtime is mapped below that.
Put the top-down allocation area below the runtime with plenty of room
to spare.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
On macOS 10.14 (Mojave), there's a system-wide VM mapping for common system
libraries starting at 0x00007fff00000000.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
