Skip to content

wasmtime-runtime fails with no_std #75

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.

Sign up for GitHub

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

Jump to bottom
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.

@jakelang jakelang mentioned this issue Apr 18, 2019
Closed
@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
@pchickey
update wasm-tools, plus minor build fix (bytecodealliance#75)
89ce28a 
* 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
@nagisa
Merge pull request bytecodealliance#75 from near/nagisa/crudely-impls…
ab7a91d 
…-ineg

zkasm: crude implementation of ineg
dhil added a commit to dhil/wasmtime that referenced this issue Jan 11, 2024
@dhil
Merge pull request bytecodealliance#75 from dhil/wasmfx-merge
3d6fef1 
Merge with upstream
abrown added a commit to abrown/wasmtime that referenced this issue Aug 1, 2024
@abrown
wasi-nn: track upstream specification
a8ea901 
In bytecodealliance#8873, we stopped tracking the wasi-nn's upstream WIT files
temporarily because it was not clear to me at the time how to implement
errors as CM resources. This PR fixes that, resuming tracking in the
`vendor-wit.sh` and implementing what is needed in the wasi-nn crate.

This leaves several threads unresolved, though:
- it looks like the `vendor-wit.sh` has a new mechanism for retrieving
  files into `wit/deps`--at some point wasi-nn should migrate to use
  that (?)
- it's not clear to me that "errors as resources" is even the best
  approach here; I've opened [bytecodealliance#75] to consider the possibility of using
  "errors as records" instead.

[bytecodealliance#75]: WebAssembly/wasi-nn#75
abrown added a commit to abrown/wasmtime that referenced this issue Aug 1, 2024
@abrown
wasi-nn: track upstream specification
d7a02b6 
In bytecodealliance#8873, we stopped tracking the wasi-nn's upstream WIT files
temporarily because it was not clear to me at the time how to implement
errors as CM resources. This PR fixes that, resuming tracking in the
`vendor-wit.sh` and implementing what is needed in the wasi-nn crate.

This leaves several threads unresolved, though:
- it looks like the `vendor-wit.sh` has a new mechanism for retrieving
  files into `wit/deps`--at some point wasi-nn should migrate to use
  that (?)
- it's not clear to me that "errors as resources" is even the best
  approach here; I've opened [bytecodealliance#75] to consider the possibility of using
  "errors as records" instead.

[bytecodealliance#75]: WebAssembly/wasi-nn#75

prtest:full
abrown added a commit to abrown/wasmtime that referenced this issue Aug 1, 2024
@abrown
wasi-nn: track upstream specification
ca07911 
In bytecodealliance#8873, we stopped tracking the wasi-nn's upstream WIT files
temporarily because it was not clear to me at the time how to implement
errors as CM resources. This PR fixes that, resuming tracking in the
`vendor-wit.sh` and implementing what is needed in the wasi-nn crate.

This leaves several threads unresolved, though:
- it looks like the `vendor-wit.sh` has a new mechanism for retrieving
  files into `wit/deps`--at some point wasi-nn should migrate to use
  that (?)
- it's not clear to me that "errors as resources" is even the best
  approach here; I've opened [bytecodealliance#75] to consider the possibility of using
  "errors as records" instead.
- this PR identifies that the constructor for errors is in fact
  unnecessary, prompting an upstream change ([bytecodealliance#76]) that should
  eventually be implemented here.

[bytecodealliance#75]: WebAssembly/wasi-nn#75
[bytecodealliance#76]: WebAssembly/wasi-nn#76

prtest:full
abrown added a commit to abrown/wasmtime that referenced this issue Aug 1, 2024
@abrown
wasi-nn: track upstream specification
92d6362 
In bytecodealliance#8873, we stopped tracking the wasi-nn's upstream WIT files
temporarily because it was not clear to me at the time how to implement
errors as CM resources. This PR fixes that, resuming tracking in the
`vendor-wit.sh` and implementing what is needed in the wasi-nn crate.

This leaves several threads unresolved, though:
- it looks like the `vendor-wit.sh` has a new mechanism for retrieving
  files into `wit/deps`--at some point wasi-nn should migrate to use
  that (?)
- it's not clear to me that "errors as resources" is even the best
  approach here; I've opened [bytecodealliance#75] to consider the possibility of using
  "errors as records" instead.
- this PR identifies that the constructor for errors is in fact
  unnecessary, prompting an upstream change ([bytecodealliance#76]) that should
  eventually be implemented here.

[bytecodealliance#75]: WebAssembly/wasi-nn#75
[bytecodealliance#76]: WebAssembly/wasi-nn#76

prtest:full
abrown added a commit to abrown/wasmtime that referenced this issue Aug 1, 2024
@abrown
wasi-nn: track upstream specification
fa7cbbc 
In bytecodealliance#8873, we stopped tracking the wasi-nn's upstream WIT files
temporarily because it was not clear to me at the time how to implement
errors as CM resources. This PR fixes that, resuming tracking in the
`vendor-wit.sh` and implementing what is needed in the wasi-nn crate.

This leaves several threads unresolved, though:
- it looks like the `vendor-wit.sh` has a new mechanism for retrieving
  files into `wit/deps`--at some point wasi-nn should migrate to use
  that (?)
- it's not clear to me that "errors as resources" is even the best
  approach here; I've opened [bytecodealliance#75] to consider the possibility of using
  "errors as records" instead.
- this PR identifies that the constructor for errors is in fact
  unnecessary, prompting an upstream change ([bytecodealliance#76]) that should
  eventually be implemented here.

[bytecodealliance#75]: WebAssembly/wasi-nn#75
[bytecodealliance#76]: WebAssembly/wasi-nn#76

prtest:full
github-merge-queue bot pushed a commit that referenced this issue Aug 1, 2024
@abrown
wasi-nn: track upstream specification (#9056)
bba5e68 
In #8873, we stopped tracking the wasi-nn's upstream WIT files
temporarily because it was not clear to me at the time how to implement
errors as CM resources. This PR fixes that, resuming tracking in the
`vendor-wit.sh` and implementing what is needed in the wasi-nn crate.

This leaves several threads unresolved, though:
- it looks like the `vendor-wit.sh` has a new mechanism for retrieving
  files into `wit/deps`--at some point wasi-nn should migrate to use
  that (?)
- it's not clear to me that "errors as resources" is even the best
  approach here; I've opened [#75] to consider the possibility of using
  "errors as records" instead.
- this PR identifies that the constructor for errors is in fact
  unnecessary, prompting an upstream change ([#76]) that should
  eventually be implemented here.

[#75]: WebAssembly/wasi-nn#75
[#76]: WebAssembly/wasi-nn#76

prtest:full
abrown added a commit to abrown/wasmtime that referenced this issue Aug 8, 2024
@abrown
WIP: sketch out wasi-nn extensions
7a9dd1f 
This change alters the `wasi-nn` world to split out two different modes
of operation:
- `inference`: this continues the traditional mechanism for computing
  with wasi-nn, by passing named `tensor`s to a `context`. Now that
  `tensor`s are resources, we pass all inputs and return all outputs
  together, eliminating `get-input` and `set-output`
- `prompt`: this new mode expects a `string` prompt which is passed
  along to a backend LLM. The returned string is not streamed, but could
  be in the future

This change also adds metadata modification of the `graph` via
`list-properties`, `get-property` and `set-property`. It is unclear
whether these methods should hang off the `context` objects instead
(TODO). It is also unclear whether the model of `load`-ing a `graph` and
then initializing it into one of the two modes via `inference::init` or
`prompt::init` is the best approach; most graphs are one or the other so
it does not make sense to open the door to `init` failures.

[bytecodealliance#74] (replace `load` with `load-by-name`) is replicated in this commit.
[bytecodealliance#75] (return errors as records) and [bytecodealliance#76] (remove the error
constructor) is superseded by this commit, since every error is simply
returned as a `string` and the `error` resource is removed.

[bytecodealliance#74]: WebAssembly/wasi-nn#74
[bytecodealliance#75]: WebAssembly/wasi-nn#75
[bytecodealliance#76]: WebAssembly/wasi-nn#76
dicej pushed a commit to dicej/wasmtime that referenced this issue Mar 14, 2025
@alexcrichton
Update wasm-tools deps for context.{get,set} (bytecodealliance#75)
724accb 
* Update wasm-tools deps for `context.{get,set}`

Also pulls in latest changes from wasmparser and such.

* More feature enabling

* Minor fixes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@alexcrichton @boomshroom @sunfishcode