Stream: git-wasmtime

Topic: wasmtime / PR #11152 fix(no_std)!: respect `std` feature ...

Wasmtime GitHub notifications bot (Jun 27 2025 at 21:18):

salmans opened PR #11152 from salmans:win-unix-no-std to bytecodealliance:main:

This PR fixes feature flag handling to properly respect the std feature when targeting Windows/Unix platforms.

Breaking Change: This fix will disable standard library features for dependents that use wasmtime with default-features = false.

Changes:

- Updated feature dependencies in Cargo.toml files to conditionally enable std-dependent features
- Added proper feature gating in runtime modules for no_std compatibility
- Modified VM system module to respect the std feature flag on Windows/Unix targets

The fix ensures that when wasmtime is used without default features, it properly builds in no_std on all supported platforms.

Wasmtime GitHub notifications bot (Jun 27 2025 at 21:19):

salmans submitted PR review.

Wasmtime GitHub notifications bot (Jun 27 2025 at 21:19):

salmans created PR review comment:

It's not clear what the dependency on rustix does here. The code compiles and passes all tests without it. Should we remove these lines?

Wasmtime GitHub notifications bot (Jun 27 2025 at 21:22):

salmans submitted PR review.

Wasmtime GitHub notifications bot (Jun 27 2025 at 21:22):

salmans created PR review comment:

We could implement and provide no_std variations of mod unix and mod windows instead of leaving it up to the user (These are the existing implementations: https://github.com/bytecodealliance/wasmtime/tree/main/crates/wasmtime/src/runtime/vm/sys).

Wasmtime GitHub notifications bot (Jun 27 2025 at 21:40):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jun 27 2025 at 22:01):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jun 27 2025 at 22:22):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jun 27 2025 at 22:31):

alexcrichton commented on PR #11152:

Thanks for the PR! Could you elaborate on the motivation for this change as well? For example I'm not aware of a target that's cfg(unix) or cfg(windows) and doesn't have std.

Wasmtime GitHub notifications bot (Jun 27 2025 at 22:34):

salmans submitted PR review.

Wasmtime GitHub notifications bot (Jun 27 2025 at 22:34):

salmans created PR review comment:

I made this change to fix cargo check -p wasmtime --no-default-features --features async,std (previously cargo check -p wasmtime --no-default-features --features async) but I'm not sure if that's an expected behavior change.

Wasmtime GitHub notifications bot (Jun 27 2025 at 22:41):

salmans commented on PR #11152:

@alexcrichton I’m experimenting with running Wasmtime (with Pulley) in the Windows kernel. The goal is to use WebAssembly to enable limited changes to kernel logic without requiring a full software update or system restart. I’m exploring Wasm as a potential alternative to eBPF for Windows.

Wasmtime GitHub notifications bot (Jun 27 2025 at 22:42):

salmans has marked PR #11152 as ready for review.

Wasmtime GitHub notifications bot (Jun 27 2025 at 22:42):

salmans requested wasmtime-core-reviewers for a review on PR #11152.

Wasmtime GitHub notifications bot (Jun 27 2025 at 22:42):

salmans requested fitzgen for a review on PR #11152.

Wasmtime GitHub notifications bot (Jun 27 2025 at 22:42):

salmans requested wasmtime-default-reviewers for a review on PR #11152.

Wasmtime GitHub notifications bot (Jun 30 2025 at 14:30):

alexcrichton commented on PR #11152:

Oh nice! Do you know if there's a #[cfg] specific to the target that you're working with that this could be keyed on instead of feature = "std"? While the breakage here isn't the end of the world and something we could document, I'd prefer to shape the change a bit differently. For example there's no testing on CI that a no_std build works on Linux/Windows so this is something that will likely easily regress over time.

Wasmtime GitHub notifications bot (Jun 30 2025 at 14:34):

bjorn3 submitted PR review.

Wasmtime GitHub notifications bot (Jun 30 2025 at 14:34):

bjorn3 created PR review comment:

mmap and the like is put behind the mm feature. It likely passes without because of the

[target.'cfg(unix)'.dependencies]
rustix = { workspace = true, optional = true, features = ["mm", "param"] }

elsewhere in this file.

Wasmtime GitHub notifications bot (Jun 30 2025 at 16:41):

salmans commented on PR #11152:

No, I don't think there's any specific target for (windows/unix) kernel. But just to clarify, are you suggesting that turning off std should still pull in standard library to avoid issues like the ones with CI? If so, an alternative solution that I can think of is to guard no_std with a new flag like override-std or force-no-std.

Wasmtime GitHub notifications bot (Jun 30 2025 at 18:24):

alexcrichton submitted PR review:

Sorry I can be more clear, my concern was a big vague there. I originally had the gut reaction of "this feels weird" but I'm effectively getting over that gut reaction. There's still changes I'd like to see in this PR, but I can try to be more clear about them. I've left various review comments below.

Wasmtime GitHub notifications bot (Jun 30 2025 at 18:24):

alexcrichton created PR review comment:

One change I'd like to see in this PR is that the std feature should not be necessary to just build the crate, even on Linux/Windows targets. In essence these CI changes shouldn't be necessary.

I tested locally and sketched out https://github.com/salmans/wasmtime/pull/1 which I believe would enable backing out these CI changes and would ensure that std is not a necessary feature even on Linux/Windows targets.

Wasmtime GitHub notifications bot (Jun 30 2025 at 18:24):

alexcrichton created PR review comment:

Can you clarify why this change was necessary? I believe the std feature here is off-by-default and never enabled by Wasmtime?

Wasmtime GitHub notifications bot (Jun 30 2025 at 18:24):

alexcrichton created PR review comment:

Mind applying this diff:

diff --git a/crates/wasmtime/src/runtime/fiber.rs b/crates/wasmtime/src/runtime/fiber.rs
index 4dcd59e532..8aa0033c4f 100644
--- a/crates/wasmtime/src/runtime/fiber.rs
+++ b/crates/wasmtime/src/runtime/fiber.rs
@@ -343,9 +343,7 @@ impl<T> StoreContextMut<'_, T> {
         self,
         f: impl FnOnce(StoreContextMut<'_, T>) -> Pin<Box<dyn Future<Output = R> + Send + '_>>,
     ) -> Result<R> {
-        BlockingContext::with(self.0, |store, cx| {
-            cx.block_on(f(StoreContextMut(store)).as_mut())
-        })
+        self.with_blocking(|store, cx| cx.block_on(f(store).as_mut()))
     }

     /// Creates a `BlockingContext` suitable for blocking on futures or
@@ -354,7 +352,6 @@ impl<T> StoreContextMut<'_, T> {
     /// # Panics
     ///
     /// Panics if this is invoked outside the context of a fiber.
-    #[allow(dead_code)]
     pub(crate) fn with_blocking<R>(
         self,
         f: impl FnOnce(StoreContextMut<'_, T>, &mut BlockingContext<'_, '_>) -> R,

to work around the need for the annotation? A bit of a hack but hopefully not too bad.

Wasmtime GitHub notifications bot (Jun 30 2025 at 18:24):

alexcrichton created PR review comment:

Yeah it's fine to drop rustix/mm here due to our preexisting dep directive and if dep:rustix can be dropped that also seems reasonable. It's perhaps already included elsewhere.

Wasmtime GitHub notifications bot (Jun 30 2025 at 18:24):

alexcrichton created PR review comment:

While theoretically possible this would primarily require an implementation of TLS in a no_std context which, as far as I know, isn't available?

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:34):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:35):

salmans submitted PR review.

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:35):

salmans created PR review comment:

Thanks you!

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:48):

salmans submitted PR review.

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:48):

salmans created PR review comment:

You're right, we don't need that change. My bad!

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:50):

alexcrichton requested alexcrichton for a review on PR #11152.

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:53):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jun 30 2025 at 21:00):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jun 30 2025 at 21:14):

salmans submitted PR review.

Wasmtime GitHub notifications bot (Jun 30 2025 at 21:14):

salmans created PR review comment:

The change resolves almost all CI issues except for stack switching checks: https://github.com/bytecodealliance/wasmtime/actions/runs/15983572956/job/45083266148?pr=11152

Wasmtime GitHub notifications bot (Jul 01 2025 at 15:30):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jul 01 2025 at 15:51):

salmans commented on PR #11152:

@alexcrichton after more experimentation on Windows, I realized win.rs in jit-icache-coherence pulls std. I'm happy to explore a no_std implementation for it in a separate PR but for now, I just pushed a new commit to disable icache coherence in Windows no_std. If that change makes sense, I'm going to address the remaining CI issues before finalizing the PR. Thanks again for your help!

Wasmtime GitHub notifications bot (Jul 01 2025 at 18:27):

alexcrichton commented on PR #11152:

For the stack switching issues can you update the stack-switching cargo feature to require std?

Wasmtime GitHub notifications bot (Jul 01 2025 at 18:43):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jul 01 2025 at 19:01):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jul 01 2025 at 19:05):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jul 01 2025 at 22:55):

alexcrichton created PR review comment:

For this it's a pretty critical operation here to manage the icache so we'll want to avoid this #[cfg] which makes it difficult to see when it's used and when it isn't. I think the best solution here might be to sidestep the problem entirely and update this line to take the std feature into account. For example that could be (unix || windows) && cfg!(feature = "std") or something like that. A comment there would be good to explain that if std is disabled then it's not supported in Wasmtime right now to interact with the OS which means that it's no longer supported.

Wasmtime GitHub notifications bot (Jul 01 2025 at 22:55):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 02 2025 at 15:28):

salmans submitted PR review.

Wasmtime GitHub notifications bot (Jul 02 2025 at 15:28):

salmans created PR review comment:

I tried that change but it doesn't solve the problem: Wasmtime still pulls std through jit-icache-coherence in no_std Windows.
Another possible solution is to use libc in jit-icache-coherence for no_std Windows at this line. For that, we could add a new std feature flag to jit-icache-coherence and enable it if std in wasmtime is enabled.

Wasmtime GitHub notifications bot (Jul 02 2025 at 17:32):

salmans updated PR #11152.

Wasmtime GitHub notifications bot (Jul 02 2025 at 17:37):

salmans submitted PR review.

Wasmtime GitHub notifications bot (Jul 02 2025 at 17:37):

salmans created PR review comment:

I just pushed a new commit that implements the change suggested above but happy to implement a different solution if this is problematic.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:27):

alexcrichton updated PR #11152.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:29):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:29):

alexcrichton created PR review comment:

Your commit looks reasonable, thanks for doing that! I'll apologize again though about how this is a bit messy. I'd prefer to avoid having the crate be sort of half-std/half-not, so I think I've come up with an idea to sidestep this entirely which is to include the icache crate only if std is enabled in Wasmtime itself. That solves the concerns I have about things getting a bit weird sometimes and the only remaining issue is various CI bits and how well this works out. I've pushed up a commit to this PR which implements what I was thinking of and I'll watch CI to see if my strategy won't work due to something I haven't thought of

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:30):

alexcrichton updated PR #11152.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:30):

alexcrichton updated PR #11152.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:43):

alexcrichton updated PR #11152.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:44):

salmans submitted PR review.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:44):

salmans created PR review comment:

Not at all! I appreciate your help and the time you've put into this. Okay, I'll wait for CI and merge the changes into the branch as soon as I see green. Thanks again!

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:47):

salmans edited PR review comment.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:49):

salmans submitted PR review.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:49):

salmans created PR review comment:

Yes, that's right. I'm resolving this for now but will explore that space for a potential future PR.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:53):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:53):

alexcrichton has enabled auto merge for PR #11152.

Wasmtime GitHub notifications bot (Jul 03 2025 at 22:29):

alexcrichton merged PR #11152.

Last updated: Dec 06 2025 at 06:05 UTC