feat(wasm): run a "hello world" wasm under an interpreter by mystor · Pull Request #58 · hawkw/mycelium

mystor · 2020-01-03T01:51:37Z

This uses a fork of the wasmi crate as the interpreter: https://github.com/mystor/wasmi/tree/mycelium.
This fork has been modified to run under our custom target, removing implicit std dependencies, and working around some missing soft-float intrinsics.

hawkw · 2020-01-03T04:22:08Z

holy cow

hawkw · 2020-01-03T04:24:49Z

src/lib.rs


+mod wasm;
+
+const HELLOWORLD_WASM: &[u8] = include_bytes!("helloworld.wasm");


:D :D :D :D

hawkw · 2020-01-03T04:25:26Z

src/lib.rs

+
+const HELLOWORLD_WASM: &[u8] = include_bytes!("helloworld.wasm");
+
 pub fn kernel_main<A>(bootinfo: &impl BootInfo<Arch = A>) -> !


this clippy lint fires a lot of false positives on tracing macros, we should just turn it off

hawkw · 2020-01-04T02:26:15Z

src/wasm/wasi.rs

+// FIXME: These should both be `u16`, and probably generated from the wasi
+// snapshot_0 `witx` definitions.


they appear to be u16s?

Oops, yeah. I fixed that. Should probably remove this comment.

hawkw · 2020-01-04T02:26:59Z

src/wasm/mod.rs

+            "unresolved global import"
+        );
+        Err(wasmi::Error::Instantiation(
+            "unresolved global import".to_owned(),


there's no way for these error strings to be static strings, is there? I'm assuming the wasmi error type is not ours...

Yup :-/. Every wasmi error has a string allocation.
if we decide to hard-fork wasmi and break the API, we could change the error type (and the lib in general) to be much less allocation-happy.

hawkw · 2020-01-04T03:40:50Z

src/wasm/mod.rs

+}
+
+host_funcs! {
+    fn "wasi_unstable"::"fd_write"(fd: u32, iovs: u32, iovs_len: u32, nwritten: u32) -> u16


TIOLI: seems like these could be idents rather than quoted?

shrug probably.
I made them strings because I think theoretically wasm supports spaces in symbols. I'm not sure we'll ever declare a symbol which has spaces in it, though, so it's probably not reasonable.

hawkw · 2020-01-04T03:41:44Z

src/wasm/mod.rs

+    }
+}
+
+macro_rules! host_funcs {


am i correct that this macro is generating all the wasi host calls (eventually)? it would be nice to have a little more documentation of all the stuff this generates & how it should be invoked (eventually)

Yeah. I threw together this macro because I needed to write a boatload of boilerplate to declare even a single host method, and didn't want to have to do it again.

We might actually want to use witx files and auto-generate the binding logic (similar to how wasmtime does since bytecodealliance/wasmtime#707), but this was much easier to get started with.

hawkw · 2020-01-04T03:42:03Z

src/wasm/mod.rs

+
+macro_rules! host_funcs {
+    ($(
+        fn $module:literal :: $name:literal ($($p:ident : $t:ident),*) $( -> $rt:ident)?


whoa, TIL that literal is an acceptable thing to match against in a macro!

Yeah, it's super handy, especially because it has an open FOLLOW set, so you don't need to be as careful with what you put after it!
Been around since ~2016 sometime, but was stabilized in rust-lang/rust#56072.

hawkw · 2020-01-04T03:42:33Z

src/wasm/mod.rs

+                index: usize,
+                args: wasmi::RuntimeArgs,
+            ) -> Result<Option<wasmi::RuntimeValue>, wasmi::Trap> {
+                let span = tracing::trace_span!("invoke_index", index, ?args);


TIOLI: seems like we could just slap a #[tracing::instrument] on the generated function?

This is the method which I was poking you on Discord about yesterday which breaks when annotated with #[tracing::instrument] due to rust messing up spans.

ah gotcha. it would be nice to have a tracing issue for that (even though it's a compiler error), just so we can reference the related issue against the compiler?

hawkw

i'm not very familiar with the wasm stuff, but this seems good to me! @iximeow, do you want to take a look before merging?

iximeow · 2020-01-08T02:23:48Z

src/helloworld.wast

+;;
+;; wat2wasm helloworld.wast
+
+(module


could we wat2wasm when building the kernel? it seems super easy to accidentally end up with a binary wasm dep in the kernel that doesn't match some associated source

That'd be pretty solid. We could also use a pure-rust wat2wasm converter (there are a few iirc) and just run it in our build script.
I just did it this way because it was the easiest, but not checking in binaries is probably a good plan.

iximeow

this is super awesome!

just the one comment about having a .wasm - i'm not sure if we even plan on later wasm blobs being built directly into the kernel. if wasms in-repo are temporary just for hello world reasons, that's fine by me!

mystor requested a review from hawkw January 3, 2020 01:51

mystor added 3 commits January 2, 2020 22:40

feat(wasm): run a 'hello world' wasm in under an interpreter

71fd410

use slice patterns for wasm signature checks

ac66d03

format using rustfmt

c9560b8

hawkw reviewed Jan 3, 2020

View reviewed changes

mystor mentioned this pull request Jan 3, 2020

feat(testing): in-qemu tests #59

Closed

hawkw reviewed Jan 4, 2020

View reviewed changes

hawkw requested a review from iximeow January 4, 2020 21:10

hawkw approved these changes Jan 4, 2020

View reviewed changes

iximeow reviewed Jan 8, 2020

View reviewed changes

iximeow approved these changes Jan 8, 2020

View reviewed changes

only store uncompiled wast in tree

2921076

mystor force-pushed the nika/wasmi branch from b56b5e6 to 2921076 Compare January 12, 2020 19:42

mystor merged commit 169e913 into master Jan 12, 2020

mystor deleted the nika/wasmi branch January 12, 2020 23:14

mystor mentioned this pull request Jan 12, 2020

milestone: run a "hello world" wasm #40

Closed


		mod wasm;

		const HELLOWORLD_WASM: &[u8] = include_bytes!("helloworld.wasm");


		const HELLOWORLD_WASM: &[u8] = include_bytes!("helloworld.wasm");

		pub fn kernel_main<A>(bootinfo: &impl BootInfo<Arch = A>) -> !

		// FIXME: These should both be `u16`, and probably generated from the wasi
		// snapshot_0 `witx` definitions.

Uh oh!

Conversation

mystor commented Jan 3, 2020

Uh oh!

hawkw commented Jan 3, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hawkw left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iximeow left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants