[PATCH] D35558: Use sys::Memory::AllocateRWX for JIT code

[Lang Hames via Phabricator via llvm-commits]

lhames added a comment.

> There are two things to consider here: the short term use for 5.0 (and I support Kamil's patch in that regard) and the long term goal.
>  The current code is a strict no-go from the NetBSD perspective: you want to turn a pure RW mapping executable, that's not allowed.
>  We have an API for expressing the desired interface, so the short term fix can be the current patch.

The current patch switches from requesting RW- pages to RWX, which I don't think is valid on iOS although I'll have to double check that.

That said, it sounds the iOS requirement (assuming I'm remembering it right) and the NetBSD one are almost identical. It sounds like we just need to switch from raw allocateMappedMemory calls to a new pair:

  allocateFutureExecutablePage(...)
  makePageExecutable(...)

On iOS this just forwards to allocateMappedMemory. On NetBSD the first call could do whatever magic is required to make the page flippable. Does that sound reasonable?

This seems achievable before rc2, and potentially safer since it doesn't change the behavior on existing platforms.

> Long term, the situation is a bit different. The problem with your approach is that it likely requires additional non-nop instructions as
>  patch point to be thread-safe. Consider incremental optimization in the JVM-JIT sense: you want to patch jumps at the beginning of
>  the function to point to any existing users to the new version. You can't just turn the page from RX to RW for that though, otherwise other
>  threads will fault.

It seems as if there are several approaches available here, depending on the target platform: If you have RWX pages you can just patch without changing permissions. Likewise if you can map the same page twice (once with RW- and once with R-X). As for nops, you can either not use them at all (do everything through indirection, though we still need to do the initial stub setup), we can make function starts patchable, or we can make call-sites patchable. Picking the right high level API should allow us experiment and/or support multiple implementations.


Repository:
  rL LLVM

https://reviews.llvm.org/D35558