Robin Lindner (Mar 28 2023 at 07:33): Robin Lindner (Mar 28 2023 at 07:33):Hey I am developing a little operating system. Is there some usage of cranelift/JIT in no_std and in kernel mode possible?
Till Schneidereit (Mar 28 2023 at 15:05):hey Robin! As a policy, we don't support no_std in either Cranelift or Wasmtime: https://docs.wasmtime.dev/stability-platform-support.html?highlight=no_std#what-about-no_std You'll have to support enough of an environment for std to work, at least for the time being
fitzgen (he/him) (Mar 28 2023 at 15:06):I'm not sure if cranelift works in no-std these days, it did at one point in time, but it is a pretty large burden on developers for miniscule gain
fwiw, you will probably get further implementing std for your OS, stubbing things out with panics as necessary, than by trying to make everything in your dep tree no-std
for context, this wasmtime doc describes some of the issues with no-std and burden on the developers: https://docs.wasmtime.dev/stability-platform-support.html#what-about-no_std
bjorn3 (Mar 28 2023 at 17:39):Give that cranelift_codegen still uses #![no_std], rust-analyzer actually prefers auto importing from core and alloc instead of std. Other than using the std re-exports in many places, and hashmaps (for which we should probably use the no_std compatible FxHashMap type alias anyway), cranelift-codegen only uses libstd in a handful of places. As such I don't think there is any burden in supporting no_std for cranelift-codegen apart from a single refactor to stop using the std re-exports. For wasmtime and cranelift-module (and dependent crates) I do agree that it is a burden.
Last updated: Dec 23 2024 at 13:07 UTC