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

Joerg Sonnenberger via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 21 02:11:46 PDT 2017


joerg added a comment.

In https://reviews.llvm.org/D35558#816891, @lhames wrote:

> > They are not allocated RWX, they are allocated RW with the option for later X. I.e. the kernel enforces W^X, but you can request additional protections for later use.
>
> When you say "additional protections" do you mean you can add the 'X' permission later (to get RWX), or just that you can later toggle from RW- to R-X?


The kernel strictly enforces W^X, so you can't request RWX. You can say "I want RW now and later maybe X" and with that to you can toggle from RW to RX (well, and back).

>> That makes sense, but it seems like the right thing then is for LLVM to change its APIs to allocate RW pages everywhere and then flip them between RW and RX. We should remove this error-prone AllocateRWX API.
> 
> From a quick grep it seems like AllocateRWX is only called from the llvm-rtdyld tool. I'll see how difficult it is to remove it. If it's easy enough we can kill it, then discuss more future-proof APIs.
> 
>> One important part LLVM needs to consider is whether it wants to enshrine the performance penalty of mprotect-after-commit in its APIs or not. The second part is whether platforms should aim to support hot-patchable JIT for multi-threaded environments or not.
> 
> For the JIT I'm hoping we can avoid having to choose by providing different implementations of a common higher-level API. 
>  Probably the StubsManager/CallbackManager level: If your platform supports hot-patching, use a HotPatchableStubsManager
>  and you get the extra performance. If not, use a SlowButSafeStubsManager and everything still works. I hope to have time
>  to prototype and sanity check that idea in a week or so.

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.

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.


Repository:
  rL LLVM

https://reviews.llvm.org/D35558





More information about the llvm-commits mailing list