The relinker writes every Linux and macOS output with execute permission since ab94ee21d7, as the running section already says, so the --autorun row no longer attributes it to --autorun.
ReadCommitCharge reads /proc/meminfo outside Windows, and macOS has no
/proc, so it returns nothing there and page 2 leaves the commit part of
its COMMIT line out, as it does for any source the run doesn't have.
The statistics test required a reading on every system, and the page 2
sampler test required the first sample to hold one.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
This reverts commit 780b33aea3, restoring the 13824 MiB direct memory pool.
With the pool at 12288 MiB, Astro Bot (PPSA21564) can no longer load its
level: DirectMemoryAllocator asserts "Can't allocate direct memory" for a
64 MB VideoPlayerTexture with 12228 of 12288 MB in use, then the process
faults about 26 s in (2 of 2 runs, RTX 4090, Linux, main cccdaa2734).
The same tree with only this merge reverted runs the full 150 s with no
direct memory assert (2 of 2 runs).
ReportAllThreads captures at most 128 other threads and prints how many
further threads were left out; the report did not list every thread of a
larger process.
GuestModuleBuilder keeps each module's directory relative to the module
parent under app0, as the Linux and Windows outputs do, so modules from
sce_modules, prx or a --module-dir do not land in app0/sce_module.
MacOsMachOPatcher::Patch discarded its lazyBinding argument, so a
module-free `--macos --lazy-binding` conversion exited 0 and wrote the
same eagerly bound Mach-O as a run without the flag. The Mach-O writer
puts every import in the LC_DYLD_INFO_ONLY bind stream and leaves the
lazy_bind stream empty, with no __la_symbol_ptr or stub helper, so the
macOS target cannot honour the flag. The patcher now throws "macOS
target does not support --lazy-binding", in the form of its
--windows-diagnostics check, so such a conversion exits 2 and writes no
output. Conversions with bundled modules were already refused by the
guest module builder.
Since 39df8e081c (fix(relinker): prefer 0x400000 for Windows
executables) the Windows main executable puts its lowest ELF load page
at 0x400000 (PE ImageBase 0x3f0000), as the runtime layout section and
the --windows-fixed-base row already say. The sandbox paragraph still
named 0x140000000, and the --trace-imports report example still showed
app.exe+0x10006 at 0x140010006.
USAGE.md's performance overlay section now gives F10's cycle (off, page
1, page 2, off) and ANYPS5_OVERLAY=2, a table with one row per line of
page 2 that names each source and the system it comes from, and what the
page costs: the trace totals it turns on while it shows, and the checks
and counters that run while the overlay is hidden or on page 1.
ENVIRONMENT.md's ANYPS5_OVERLAY row lists page 2.
The relinker binary carried no build identity: a release build and a
checkout of main were indistinguishable, so a report could not name the
build it came from. --version prints the revision git describe reports,
falling back to "unknown" when the tree has no git metadata, and needs
no input or output paths. The usage line and USAGE.md list the option.
Dean