iOS: support JIT on iOS 26 (TXM/SPTM devices)

[Johnzx07]

Problem

On iOS 26, on TXM/SPTM hardware (A15+ / M2+), the iOS JIT path can no longer produce executable memory. Recompiled blocks fault the moment they are entered, so games stop booting once JIT is enabled. This is the cause of jpd002/Play-#1490.

Probing on an iPhone 15 Pro Max (A17 Pro) running iOS 26.4.2 shows the process has no way to do it itself:

attempt	result
mmap(..., MAP_JIT)	EPERM — requires the dynamic-codesigning entitlement
mmap(PROT_READ|WRITE|EXEC)	maps, reports max=rwx, but current is rw-
mprotect(..., PROT_READ|PROT_EXEC) on the above	returns 0 but the page ends up r--, max=rw- — execute is stripped
existing MEMFUNC_USE_MACHVM vm_protect path	same failure

CS_DEBUGGED was set in all of these, so having a debugger attached is not by itself sufficient.

Mechanism

The only thing that marks a page executable on these devices is a write performed out of process by an attached debugger: for every 16K page, debugserver writes one byte, and that write grants the page execute permission.

StikDebug / StikJIT implement the debugger half and wait for the app to ask for it through a breakpoint protocol — brk #0xf00d, command in x16, arguments in x0/x1. The app has to be the client; simply having the debugger attached does nothing on its own.

Documented in StikJIT's INTEGRATION.md:

Where TXM/SPTM is present, the debugger flag alone is not enough: each executable memory region must be prepared through the debug connection before the app executes code from it.

Changes

Implements the client half for the iOS arm64 build, in MemoryFunction.cpp:

• A single 64MB region is requested from the debugger with a NULL address, selecting its fresh-allocation branch. Passing an address the process mapped itself returns the same pointer and appears to succeed, but no memory-write packets are ever sent and the region never becomes executable.
• The returned region is execute-only, so a writable alias of the same physical pages is created locally with vm_remap + vm_protect.
• Blocks are sub-allocated from that pair (first-fit free list + bump). m_code stays the executable address; a new GetWritableCode() returns the matching writable address for callers that patch generated code in place.
• Gated on CS_DEBUGGED — a brk with no debugger attached raises an unhandled SIGTRAP and kills the process.
• The debugger is deliberately never detached; execute permission is tied to it staying attached.

MemFunc_InitJitArena() lets the app reserve the region early in launch, while the debugger's script is still running. MemFunc_IsJitReady() reports whether an executable region was actually obtained. No-op stubs keep non-TXM Apple targets (including the simulator) linking.

There is a companion change in Play- — BasicBlock's link patching must write through GetWritableCode(), and the iOS UI calls MemFunc_InitJitArena() / MemFunc_IsJitReady(). Happy to open that PR once this is reviewed, or fold it in however you prefer.

Nothing changes on any other platform — macOS, Windows, Linux, Android, Emscripten and the iOS simulator all take the same paths as before.

Testing

Verified on an iPhone 15 Pro Max (A17 Pro), iOS 26.4.2, running under LiveContainer with StikDebug and its universal.js script: games boot and run with JIT. Previously they black-screened or crashed on entering recompiled code.

Credit to StikDebug/StikJIT for the protocol, and to shadPS4's ios_jit_allocator, which documented both pitfalls above (the NULL-address branch and the execute-only region) from on-device wire tracing.

🤖 Generated with Claude Code

[Johnzx07]

Pushed a follow-up commit hardening the region acquisition, and this is now verified on iOS 26.4.2 and 26.6.2 (iPhone 15 Pro Max, A17 Pro, same hardware both times so the OS version was the only variable).

26.6 is worth calling out specifically, because it broke JIT in several other apps. Apple enabled TXM on more devices in that update, so anything that detects TXM and picks a code path from it gets a stale answer after updating and ends up on a path that can't produce executable memory. This implementation deliberately doesn't do that — the debugger request is simply the first thing tried on every iOS arm64 device, with a fallback if it doesn't produce a region — so there's nothing to go stale.

The follow-up also fixes a real correctness bug: an unserviced breakpoint doesn't reliably return null. The breakpoint encoding can be left behind in x0, so values like 0x690000e0 were being accepted as a valid address. The result is now validated rather than null-checked, with a short retry in case the debugger's script is momentarily busy.

Happy to squash these into a single commit if you'd prefer, and to open the companion Play- change (block link patching through GetWritableCode(), plus the two calls from the iOS UI) whenever suits you.

🤖 Generated with Claude Code