Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasmtime-runtime fails with no_std #75

Closed
boomshroom opened this issue Mar 27, 2019 · 3 comments
Closed

wasmtime-runtime fails with no_std #75

boomshroom opened this issue Mar 27, 2019 · 3 comments

Comments

@boomshroom
Copy link

The wasmtime-runtime crate (which wasmtime-jit depends on) has a crate feature specifying that it can be built without std, but attempting to do so fails. Looking at the code, it does appear to reference the std crate without any guards or reexports, but the bigger issue is trying to build the signal handlers, which require compiling for a target OS, something which doesn't work when using no_std.

As mentioned earlier, wasmtime-jit has wasmtime-runtime as a direct dependency, and it also provides a no_std feature.

@sunfishcode
Copy link
Member

Yes, I started adding no_std support a while ago because it's something I'm interested in, however signal handling and mmap/mprotect are two things that Wasmtime currently uses which aren't available in no_std.

One thing we could do is have an option to disable the mmap/signal-based linear memory sandboxing, and to just tell Cranelift to do linear-memory sandboxing with bounds checking, which would fix some of the problem.

However, the other problem is that we need mmap/mprotect to allocate JIT code and make it executable. It's not clear how we should do that in no_std code.

@boomshroom
Copy link
Author

How about using a trait and asking the caller to supply implementations that would normally be handled by the host? For example, a kernel embedding would implement the linear memory allocations with direct page mapping, while the default std implementation uses mmap and mprotect.

@alexcrichton
Copy link
Member

I don't think this is relevant any more after #554, so I'm going to close this

pchickey added a commit to pchickey/wasmtime that referenced this issue May 16, 2023
* bump wasm-tools to latest releases

* wit-component includes upstream fixes, plus wasm-metadata
* update wasm-encoder to match

* test-programs build.rs: use `cargo +nightly` flag to ensure nightly

on CI, rustup has the default set to nightly, but this may not be the
case on developer machines

* invoke cargo nightly through rustup
mooori pushed a commit to mooori/wasmtime that referenced this issue Dec 20, 2023
…-ineg

zkasm: crude implementation of ineg
dhil added a commit to dhil/wasmtime that referenced this issue Jan 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants