You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Activity
sunfishcode commentedon Mar 28, 2019
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_stdcode.boomshroom commentedon Apr 12, 2019
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 commentedon Feb 1, 2020
I don't think this is relevant any more after #554, so I'm going to close this
update wasm-tools, plus minor build fix (bytecodealliance#75)
Merge pull request bytecodealliance#75 from near/nagisa/crudely-impls…
Merge pull request bytecodealliance#75 from dhil/wasmfx-merge
wasi-nn: track upstream specification
wasi-nn: track upstream specification
wasi-nn: track upstream specification
wasi-nn: track upstream specification
wasi-nn: track upstream specification
wasi-nn: track upstream specification (#9056)
WIP: sketch out wasi-nn extensions
Update wasm-tools deps for `context.{get,set}` (bytecodealliance#75)