After trying for a few months to get the Region crate ported and merged upstream, I’ve made the discovery that the Haiku native API based on create_area() as its allocation subroutine calls another subroutine disallows some memory-protection bit combinations required by the Region crate’s API as indicated by the unit tests. In order to port the CraneLift JIT compiler or the Wasmer or Wasmtime runtime engines, either Haiku or Region’s API will need to change. Otherwise they are mutually exclusive.
Options:
Add a POSIX style allocation and memory protection set of subroutines borrowed from a BSD dialect and make them less picky than the normal create_area() routine.
Write a group letter or email to the author of the Region crate to make our plea that he change the Region crate to not need the Protection::NONE configuration in which the allocated Area will be neither readable, writable nor executable as a temporary state at least.
Make potentially compatibility-altering changes to Haiku’s Area handling virtual-memory support. (This is obviously an unlikely last-resort.)
I’m leaning toward option 2 and if necessary, this message can be cross-posted to the developers’ mailing lists. This can severely curtail my efforts to port a WebAssembly runtime engine (outside the browser) based on the WASI API to Haiku.
Other options are welcome as well if anyone can find any.
Changing protection bits with mprotect is exactly what my port is doing. The problem is that if I use nonstandard protection bits in the first place they don’t appear to even allocate. Maybe I should try allocating as read/write and THEN change the protection bits. That might work. Thanks x512!
I don’t think that is going to be viable because it would break compatibility with the world. It would certainly break legacy software. If Rust really can’t be flexible enough to work with it as-is, not a great advertisement for Rust.
What do you need exactly? We already have mmap and mprotect, which is what is usually used in BSD and Linux for this. Why are these not working for your needs?
Yes, we have ports of V8 and JavaScriptCore, both of which have JITs and both of which have support for WebAssembly, and they both work just fine (although there were some Haiku bugs over the years uncovered by them that we had to fix.) They use the already-existing POSIX allocation and memory protection functions. So @SamuraiCrow will have to be more specific as to what, exactly, the Region crate needs that somehow WebKit and friends have not.
Rust does not depend on the Region crate. Please don’t over-generalize. The Region crate is used by Wasmer, Wasmtime and most importantly, the Cranelift JIT. Cranelift generates nearly the same quality code as LLVM in a fraction of the time. It’s currently the best JIT available.
@all
I’m going to try to allocate and mprotect memory in separate steps to see if I was just jumping to a hasty conclusion. If that works, we’ll have a workaround. If it doesn’t, we can look into other options then.
The stand-alone API for WebAssembly is called the WebAssembly System Interface, abbreviated WASI. It has a POSIX subset protocol like Haiku implements. I thought having ready-made runtimes for WASI would be a good starting point especially if we could pull in compilers and other programs from other platforms.
It’s possible to decode WebAssembly directly into native binaries rather than the WASI runtimes but then that would be merely cross architecture instead of truly cross platform. It’s still useful but then I’d still have to make a wrapper for the entire Haiku API. If making a wrapper for the Area handling (paging) of the Haiku kernel is taking months, just imagine trying to wrap the whole API. It would take longer yet.
I see WASI as a means of “toppling the apple-cart” and throwing the competition “out the window”. Of course software written in the WASI API will still work on the others but shifting the burdens around will cut into their power-base letting the little guys have a chance. WASI is an equalizer.