Lucky4Luuk commented on issue #1158:
Is this still being worked on? What are the current issues blocking no_std support?
alexcrichton added the wasmtime:platform-support label to Issue #1158.
alexcrichton commented on issue #1158:
I'm at least not personally aware of this being worked on, but no blocker other than "just needs some elbow grease". If you'd be up for it PRs would be most welcome!
marceline-cramer commented on issue #1158:
I made a pretty half-assed attempt at this but managed to dig up some useful info: a major blocker to getting this to work is getting several dependencies involved in
std::io::Write
-ing to objects to work onno_std
. Here's a non-exhaustive list (i've been doing this for hours and i am exhausted enough):
- the
leb128
crate used bywasm-encoder
has a hard dependency onstd::io
- the
termcolor
crate has a hard dependency onstd::io
indexmap/std
is enabled bywasmparser/std
is enabled bywasmprinter
(which has no features that could be used to disable the dep feature)gimli/write
has a hard dependency onstd::io
object/write
has a hard dependency onstd::io
All of those issues come from the
wasmtime-environ
crate with thecompile
feature, which as far as I can tell, is pretty necessary to the functioning ofwasmtime-cranelift
. I don't know how necessary that is, but if it is absolutely crucial to havecompile
working, those crates need to be either factored out, guarded behindstd
, or in the worst case, modified upstream to not usestd::io
. Much bureaucracy ensues.The really obnoxious part about removing
std::io
from those crates is that there is no equivalentio
API incore
oralloc
, making ergonomicno_std
a great endeavor per project.Aside from
wasmtime-environ
,wasmtime-codegen/unwind
has a similar breaking dependency ongimli/write
for itswrite
feature, which usesstd::io
to write objects. Disabling theunwind
feature also causes a cascade of missing API items in thewasmtime-codegen
crate ANDwasmtime-cranelift
. Today, I did manage to getwasmtime-codegen
compiling locally inno_std
but because I hadn't gotten theunwind
feature to work I had to give up.
thread_local
also breaks inwasmtime-codegen
because that'sstd
-only. I managed to take care of that with nightly#[thread_local]
for now but obviously that's not optimal. More research is needed.
OnceLock
can be replaced withonce_cell::OnceCell
trivially, although that uses the scary-soundingcritical-section
feature. More research is needed.My personal opinion is that the best way to keep
no_std
supported in the future is to just makewasmtime-codegen
no_std
-only. It only seems to be defining complex types of its own without a whole lot of interop with standard library types or interfaces anyways, and it was surprisingly easy to root out all of thestd
-specific code.std
does provide hash maps, butrustc-hash
,hashbrown
, andahash
are already in the dependency tree.I haven't tried to get
thiserror
working yet but I will.I would really appreciate some guidance for what to work towards next. This is clearly going to take a LOT of work to get
wasmtime-cranelift
working onno_std
consistently on all platforms but I'm pretty invested in it. Also, if I've made any mistakes in my probing (I'm a newcomer to the codebase), please let me know.
marceline-cramer edited a comment on issue #1158:
I made a pretty half-assed attempt at this but managed to dig up some useful info: a major blocker to getting this to work is getting several dependencies involved in
std::io::Write
-ing to objects to work onno_std
. Here's a non-exhaustive list (i've been doing this for hours and i am exhausted enough):
- the
leb128
crate used bywasm-encoder
has a hard dependency onstd::io
- the
termcolor
crate has a hard dependency onstd::io
indexmap/std
is enabled bywasmparser/std
is enabled bywasmprinter
(which has no features that could be used to disable the dep feature)gimli/write
has a hard dependency onstd::io
object/write
has a hard dependency onstd::io
All of those issues come from the
wasmtime-environ
crate with thecompile
feature, which as far as I can tell, is pretty necessary to the functioning ofwasmtime-cranelift
. I don't know how necessary that is, but if it is absolutely crucial to havecompile
working, those crates need to be either factored out, guarded behindstd
, or in the worst case, modified upstream to not usestd::io
. Much bureaucracy ensues.The really obnoxious part about removing
std::io
from those crates is that there is no equivalentio
API incore
oralloc
, making ergonomicno_std
a great endeavor per project.Aside from
wasmtime-environ
,wasmtime-codegen/unwind
has a similar breaking dependency ongimli/write
, which usesstd::io
to write objects. Disabling theunwind
feature also causes a cascade of missing API items in thewasmtime-codegen
crate ANDwasmtime-cranelift
. Today, I did manage to getwasmtime-codegen
compiling locally inno_std
but because I hadn't gotten theunwind
feature to work I had to give up.
thread_local
also breaks inwasmtime-codegen
because that'sstd
-only. I managed to take care of that with nightly#[thread_local]
for now but obviously that's not optimal. More research is needed.
OnceLock
can be replaced withonce_cell::OnceCell
trivially, although that uses the scary-soundingcritical-section
feature. More research is needed.My personal opinion is that the best way to keep
no_std
supported in the future is to just makewasmtime-codegen
no_std
-only. It only seems to be defining complex types of its own without a whole lot of interop with standard library types or interfaces anyways, and it was surprisingly easy to root out all of thestd
-specific code.std
does provide hash maps, butrustc-hash
,hashbrown
, andahash
are already in the dependency tree.I haven't tried to get
thiserror
working yet but I will.I would really appreciate some guidance for what to work towards next. This is clearly going to take a LOT of work to get
wasmtime-cranelift
working onno_std
consistently on all platforms but I'm pretty invested in it. Also, if I've made any mistakes in my probing (I'm a newcomer to the codebase), please let me know.
marceline-cramer edited a comment on issue #1158:
I made a pretty half-assed attempt at this but managed to dig up some useful info: a major blocker to getting this to work is getting several dependencies involved in
std::io::Write
-ing to objects to work onno_std
. Here's a non-exhaustive list (i've been doing this for hours and i am exhausted enough):
- the
leb128
crate used bywasm-encoder
has a hard dependency onstd::io
- the
termcolor
crate has a hard dependency onstd::io
indexmap/std
is enabled bywasmparser/std
is enabled bywasmprinter
(which has no features that could be used to disable the dep feature)gimli/write
has a hard dependency onstd::io
object/write
has a hard dependency onstd::io
All of those issues come from the
wasmtime-environ
crate with thecompile
feature, which as far as I can tell, is pretty necessary to the functioning ofwasmtime-cranelift
. I don't know how necessary that is, but if it is absolutely crucial to havecompile
working, those crates need to be either factored out, guarded behindstd
, or in the worst case, modified upstream to not usestd::io
. Much bureaucracy ensues.The really obnoxious part about removing
std::io
from those crates is that there is no equivalentio
API incore
oralloc
, making ergonomicno_std
a great endeavor per project.Aside from
wasmtime-environ
,wasmtime-codegen/unwind
has a similar breaking dependency ongimli/write
, which usesstd::io
to write objects. Disabling theunwind
feature also causes a cascade of missing API items in thewasmtime-codegen
crate ANDwasmtime-cranelift
. Today, I did manage to getwasmtime-codegen
compiling locally inno_std
but because I hadn't gotten theunwind
feature to work I had to give up.
thread_local
also breaks inwasmtime-codegen
because that'sstd
-only. I managed to take care of that with nightly#[thread_local]
for now but obviously that's not optimal. More research is needed.
OnceLock
can be replaced withonce_cell::OnceCell
trivially, although that uses the scary-soundingcritical-section
feature. More research is needed.I haven't tried to get
thiserror
working yet but I will.I would really appreciate some guidance for what to work towards next. This is clearly going to take a LOT of work to get
wasmtime-cranelift
working onno_std
consistently on all platforms but I'm pretty invested in it. Also, if I've made any mistakes in my probing (I'm a newcomer to the codebase), please let me know.
bjorn3 commented on issue #1158:
#[thread_local]
is generally unavailable on no_std targets too.
alexcrichton commented on issue #1158:
My recommendation would be to first start off by gating "easy" things behind on-by-default Cargo features. For example
wasmprinter
doesn't need to be included in no_std builds (northread_local
usage ortermcolor
). Basically anything that's optional functionality can be hard-disabled at compile time and that can greatly help to prune the dependency tree of crates that don't support no_std.After that next bit that I would recommend is to do this incrementally. The main crate in question I believe is
cranelift-codegen
but there are other crates as well that it depends on. I'd recommend starting at the leaves (e.g.cranelift-entity
) and adding a "ratchet" to add support forno_std
to ensure they don't regress. For example on CI you'd add lines around here where that ensures that crates build on a no_std target. Eventually as you work your way up tocranelift-codegen
you'll already have added support to a number of other crates and handled a number of these issues.At that point I think it might be worth reevaluating taking stock of what's remaining. I think it would be useful to classify dependencies as you've done, but with a refreshed list at that point. Some of these are going to be somewhat hard like
gimli/write
andobject/write
but we might be able to work with upstream to have new crate versions that support no_std needs, but that also sort of depends on what exactly Cranelift needs. That's why I'd recommend doing everything exceptcranelift-codegen
first if possible so we can get the most precise picture of what Cranelift needs from its dependencies with no_std.
marceline-cramer commented on issue #1158:
I'm having a hard time with removing
thread_local
usage fromcranelift/codegen/src/timing.rs
. What alternative tothread_local
statics should I use withno_std
, if any? As far as I can tell, thetiming
module and those statics can't be configured out. One idea I have is to just configure out all thetiming
usage with API-compatible no-op stub functions onno_std
, but I don't know enough about the codebase to understand the consequences of something like that.
marceline-cramer edited a comment on issue #1158:
I'm having a hard time with removing
thread_local
usage fromcranelift/codegen/src/timing.rs
. What alternative tothread_local
statics should I use withno_std
, if any? As far as I can tell, thetiming
module and those statics can't be configured out. One idea I have is to just configure out all thetiming
usage with API-compatible no-op stub functions onno_std
, but I don't know enough about the codebase to understand the consequences of something like that.I should also point out that the
set_thread_profiler()
function is not used anywhere in the codebase.
marceline-cramer commented on issue #1158:
For now, I just put no-op stubs in the
timing
API when thetiming
feature is not enabled and made thetiming
feature enable thestd
feature automatically.thread_local! {}
is still in use as long as thetiming
feature is enabled.Right now, my development approach is to hack on all of these intersecting API changes and changes to the dependency trees on a fork, which I have set up to be running the full CI PR test suite: https://github.com/marceline-cramer/wasmtime/pull/1 Once that branch on my fork is to a place I'm happy with and all the pieces fit together practically as a rough sketch, I can start decomposing it into finer-grained, more polished things to implement as upstream-facing PRs. I did implement the "ratcheting" approach to get down to
cranelift-codegen
as quickly as I could and discovered all but one of its workspace dependencies already work fine inno_std
. The one exception wascranelift-control
, which to compile tono_std
I slapped in a Git dep for a pending PR onarbitrary
withno_std
support: https://github.com/rust-fuzz/arbitrary/pull/177I added a field to
CodegenOptions
incranelift-isle
to emitno_std
-compatible code by adding a short prelude to generated source files, because most CI compiles ISLE withstd
butcranelift-codegen
does not. If that's an acceptable change for upstream, I'd be happy to make a little PR to get that moving along.The reason I had gotten as far with
cranelift-codegen
as to be hacking onthread_local
is because getting it to compile to ano_std
target turned out to be pretty easy. I mainly just swapped out all of the uses ofrustc-hash
with a combination ofhashbrown
andahash
and replaced any lingering uses ofstd
withcore
andalloc
. I also replaced any use of floating-point arithmetic in the instrinics code with thecore_math
crate, which just implementsstd
-compatible arithmetic operators oncore
floats usinglibm
. There may be some security concerns with regards to the use ofahash
in ano_std
environment but I have decided that taking a deeper look into that is Tomorrow Marceline's problem.The main kicker with
cranelift-codegen
right now is that so far, I've only gottenall-arch
andtrace-log
features, with no others, to compile, and only in nightly. The reason it has to be in nightly for now is because there are some cases ofimpl std::error::Error
that I'm too afraid tocfg
out, so for now I'm using nightly andcore::error::Error
until I can figure out what to do with potentialno_std
API users ofcranelift-codegen
. I figure that the already-discussed use ofthiserror
onno_std
would force us to use nightly for now anyways.That's about where I am now. The CI mostly passes, although Cranelift's unit tests fail with slightly different code output compared to the expected code. I can chalk that up to either an impatient use of
cargo update
that may have minorly changed some semantics of dependencies involved in codegen, or something related to the switching ofrustc-hash
tohashbrown
. Both are easy to test.The main issue now is that, by default,
cranelift-codegen
is configured to havestd,unwind,trace-log
enabled.trace-log
works inno_std
independently ofstd
, butunwind
is still blocked by that peskygimli/write
dep and its use ofstd::io
. I can take a deeper look into how exactly that is used and what an alternative to that either in Cranelift or upstream Gimli might look like when I have more time and can afford to lock in on specific issues like that. I'm becoming a lot more comfortable navigating the codebase but there's still a lot of cognitive overhead and even swapping out dependencies takes a lot of attention.
bjorn3 commented on issue #1158:
I should also point out that the set_thread_profiler() function is not used anywhere in the codebase.
It is used by cg_clif to include performance timings collected by Cranelift in rustc self profile profiles. Having thr timing module be a nop for no_std builds is fine.
bjorn3 commented on issue #1158:
I added a field to CodegenOptions in cranelift-isle to emit no_std-compatible code by adding a short prelude to generated source files
Unconditionally using core instead of std should work fine. In std builds, core is still available.
alexcrichton commented on issue #1158:
For now, I just put no-op stubs in the timing API when the timing feature is not enabled and made the timing feature enable the std feature automatically
Sounds good! I'd recommend gating
set_thread_profiler
behind this Cargo feature entirely (and having the feature enabled by default probably too). That would avoid the confusion of callingset_thread_profiler
and having it do nothing.The one exception was cranelift-control, which to compile to no_std I slapped in a Git dep for a pending PR on arbitrary with no_std support: https://github.com/rust-fuzz/arbitrary/pull/177
I'd probably recommend adding a
fuzz
feature or similar to avoid needing to update thearbitrary
crate (although updating that is definitely ok too). Basically gating this functionality on a Cargo feature is fine. (this Cargo feature may even be able to be off-by-default too)I also replaced any use of floating-point arithmetic in the instrinics code with the core_math crate, which just implements std-compatible arithmetic operators on core floats using libm. There may be some security concerns with regards to the use of ahash in a no_std environment but I have decided that taking a deeper look into that is Tomorrow Marceline's problem.
This sounds generally fine and possible for us to land. When making PRs if you wouldn't mind leaving
cranelift-codegen
's no_std support for a single standalone PR that'll make this easiest to review and discuss.The main kicker with cranelift-codegen right now is that so far, I've only gotten all-arch and trace-log features
FWIW I think it's definitely ok to not get the entire crate and all its features compiling with no_std. Only getting a subset working (albeit we still need a useful subset, but the one you have is useful) is more than ok. Can always work to improve the subset supported later on.
The reason it has to be in nightly for now is because there are some cases of impl std::error::Error
I'm assuming that you're probably going to add a
std
feature to thecranelift-codegen
crate no matter what, and would it be possible to gate these impls on thestd
feature? That is, "just" omit them for a no_std build?The main issue now is that, by default, cranelift-codegen is configured to have std,unwind,trace-log enabled
In the spirit of ratcheting and progress over time I'll reiterate it's completely ok to get only some features working and not others. In this workspace most dependencies disable default features and then individual crates will enable features in addition to specifying
workspace = true
. That would enable a state wherecranelift-codegen
itself builds with no_std butwasmtime-cranelift
doesn't work just yet. That'd help figure out all the dependencies as we go along and get to a working state at least for one crate while the blockers of the next crate are tackled.One example here is that the
unwind
feature is only used in Wasmtime forConfig::native_unwind_info
which would be easy to gate behind a Cargo feature. In that sense there's no need to unconditionally enableunwind
in Cranelift given possible future changes.If your target is
wasmtime-cranelift
the bigger problem is probably going to beobject::write
as that's pretty intrinsically depended on. It's probably best to cross that bridge when we get there though and it's the "only" remaining issue. If your target is justcranelift-codegen
onno_std
then you can disregard this last part from me :)
marceline-cramer commented on issue #1158:
I added a field to CodegenOptions in cranelift-isle to emit no_std-compatible code by adding a short prelude to generated source files
Unconditionally using core instead of std should work fine. In std builds, core is still available.
It would work fine if not for the
impl Length for Vec
in the codegen. In no_std, that would have to be replaced with thealloc
crate, and no_std or not, thealloc
crate has to be manually declaredextern crate alloc;
.
marceline-cramer commented on issue #1158:
Sounds good! I'd recommend gating
set_thread_profiler
behind this Cargo feature entirely (and having the feature enabled by default probably too). That would avoid the confusion of callingset_thread_profiler
and having it do nothing.Sounds great, I'll remember that when I open the
cranelift-codegen
no_std
PR.I'd probably recommend adding a
fuzz
feature or similar to avoid needing to update thearbitrary
crate (although updating that is definitely ok too). Basically gating this functionality on a Cargo feature is fine. (this Cargo feature may even be able to be off-by-default too)Not including the
arbitrary
crate breaksControlPlane::arbitrary()
andControlPlane::get_arbitrary()
, so I've made it on by default so that none of the dependencies need to manually enable it. We can discuss that more in thecranelift-control
PR I'm about to open. :)This sounds generally fine and possible for us to land. When making PRs if you wouldn't mind leaving
cranelift-codegen
's no_std support for a single standalone PR that'll make this easiest to review and discuss.FWIW I think it's definitely ok to not get the entire crate and all its features compiling with no_std. Only getting a subset working (albeit we still need a useful subset, but the one you have is useful) is more than ok. Can always work to improve the subset supported later on.
I'm assuming that you're probably going to add a
std
feature to thecranelift-codegen
crate no matter what, and would it be possible to gate these impls on thestd
feature? That is, "just" omit them for a no_std build?Yeah, I suppose that is definitely the easiest way of going about it. I would definitely be glad to have just stripped-down
cranelift-codegen
working inno_std
upstream for now.One example here is that the
unwind
feature is only used in Wasmtime forConfig::native_unwind_info
which would be easy to gate behind a Cargo feature. In that sense there's no need to unconditionally enableunwind
in Cranelift given possible future changes.If your target is
wasmtime-cranelift
the bigger problem is probably going to beobject::write
as that's pretty intrinsically depended on. It's probably best to cross that bridge when we get there though and it's the "only" remaining issue. If your target is justcranelift-codegen
onno_std
then you can disregard this last part from me :)I was not aware that the dependency on
unwind
was so light, glad to hear! Yes, I am most interested in using the entirety of Wasmtime JIT functionality itself in ano_std
environment. Once I can get the lower-level features working though I'll see what I can get done with theobject
crate and I'll come back here to make the rest of the push. :)
Last updated: Dec 23 2024 at 12:05 UTC