[aparashk]

"If an app marks a page executable at runtime (such as a JIT) it will interpret that."

Was that from a presentation on Rosetta2 that I have missed? It certainly makes sense, but also you'd need to watch for writes to executable pages that have been already AOT translated.

[cormacrelf]

JITs usually mark +x pages -w again after they've written them for sanity, so watching in platform libc mprotect could do it, but you could also force them to be -w anyway and then maybe use the page fault handler. How much integration with the kernel does it have?

[littlecranky67]

Javascript being the extreme example here (no one is going to run Chrome or Firefox in Rosetta2 probably) but it is re-JITing very often (I think Firefox starts with interpreting JS code, and then replaces hot code paths with JIT compiled equivalents when they become available).

I also see issues with self-modifying code, but this is also very rare (I knew some .NET code that was injecting/manipulating its own JIT code to go around C# private/protected encapsulation).

[The_Colonel]

> no one is going to run Chrome or Firefox in Rosetta2 probably

Browsers themselves no, but there's many apps out there based on browser tech (e.g. electron apps). Also many apps shipping with their own JVM or other JIT engine.

Anecdote incoming, my pet project is based on electron, I am currently building a mac x86 version but don't plan to ship an ARM version (since testing it without an actual physical mac is going to be even more difficult / impossible).

[wtallis]

> but also you'd need to watch for writes to executable pages that have been already AOT translated.

Wouldn't executable pages (translated or not) normally be mapped as read-only, ensuring the processor faults on any attempt to modify them?

[cormacrelf]

Ah, the question is whether Darwin enforces W^X, because if so, the problem becomes very easy. Then you re-translate whenever a page becomes executable [again].

[my123]

On Arm 64-bit Darwin, W^X is enforced at all times.