Extend wasi-emulated-mman with mprotect

[whitequark]

This implementation never changes actual memory protection, but it does verify that the address range and flags are valid. The direct motivation is fixing a linker error where LLVM links to mprotect in dead code.

[sbc100]

Would it make sense if patch LLVM to honor some kind of HAVE_MPROTECT instead/also?

[whitequark]

Would it make sense if patch LLVM to honor some kind of HAVE_MPROTECT instead/also?

That's what I've been doing so far, but:

a) There is pushback against adding more compiletests, as they are slow and some find them hard to maintain.
b) A sensible implementation for wasi-emulated-mman is possible, so why not add it here? It may benefit other applications.

[sbc100]

Would it make sense if patch LLVM to honor some kind of HAVE_MPROTECT instead/also?

That's what I've been doing so far, but:

a) There is pushback against adding more compiletests, as they are slow and some find them hard to maintain.

Do they need to be compiletests? Can't it just be something that is hardcoded into the CMakeLists on the LLVM side? something like:

if (IS_WASM) set(HAVE_MMAP, 0)

b) A sensible implementation for wasi-emulated-mman is possible, so why not add it here? It may benefit other applications.

Fair enough, I agree it makes sense to emulate all these mman symbols.

However I do think it would be better for llvm to not include the dead code that calls mmap/mprotect at all. It seems like a good in general. Perhaps we can do both things?

[whitequark]

Can't it just be something that is hardcoded into the CMakeLists on the LLVM side? something like:

Maybe, but I still don't understand exactly what changes to CMakeLists.txt for WASI will be upstreamable, and it seems there are objections to having those #defines in config.h.cmake too. So for now I'm avoiding doing any speculative work. If the current set of compiletests is accepted then one more for mprotect() is probably fine too (but I must point out that it will require a different approach because wasi-libc advertises support for mprotect() in the headers; it just doesn't have the symbol).

However I do think it would be better for llvm to not include the dead code that calls mmap/mprotect at all. It seems like a good in general. Perhaps we can do both things?

It looks like there's currently no way to disable the JIT (which is a little odd to me), which is what probably needs to be done for this. LTO builds don't suffer from this problem, so the code is already statically dead, just not dead enough for non-LTO builds.

[sunfishcode]

Looks good to me.

[whitequark]

Thanks!