feat(wamr): add wasm-mico-runtime shim implementation #716
Conversation
…error upstream to the official wamr SDK solves this issue Signed-off-by: jiaxiao zhou <[email protected]>
I believe there are more work to be done to parse the runtimeError
to appropriate exit code.
failures:
wamr_tests::test_custom_entrypoint
wamr_tests::test_exit_code
wamr_tests::test_hello_world_oci
wamr_tests::test_seccomp
wamr_tests::test_unreachable
Signed-off-by: jiaxiao zhou <[email protected]>
…lows Signed-off-by: jiaxiao zhou <[email protected]>
Signed-off-by: jiaxiao zhou <[email protected]>
| .or_else(|err| { | ||
| log::error!("Error: {:?}", err); | ||
| Err(err) | ||
| }) |
There was a problem hiding this comment.
we should parse the RuntimeError to appropriate exit code. Any thoughts on this one, @lum1n0us?
There was a problem hiding this comment.
Regarding that, I just noticed that WAMR only uses error strings to convey information if something goes wrong during the execution of a Wasm function. So, if it's okay, can we continue to display the error string in the log and use a simple -1 and 0 to indicate failure and success, respectively?
There was a problem hiding this comment.
I was looking for exit code that can pass this test: https://github.com/containerd/runwasi/blob/main/crates/containerd-shim-wasmer/src/tests.rs#L79-L88
There was a problem hiding this comment.
For example, how can I get exit code 42 from running this wasm module?
(module
;; Import the required proc_exit WASI function which terminates the program with an exit code.
;; The function signature for proc_exit is:
;; (exit_code: i32) -> !
(import "wasi_snapshot_preview1" "proc_exit" (func $proc_exit (param i32)))
(memory 1)
(export "memory" (memory 0))
(func $main (export "_start")
(call $proc_exit (i32.const 42))
unreachable
)
)
There was a problem hiding this comment.
We have a fix for this situation. Please have a look.
Signed-off-by: jiaxiao zhou <[email protected]>
|
@lum1n0us do you know why the entrypoint_test failed? thread 'wamr_tests::test_custom_entrypoint' panicked at crates/containerd-shim-wamr/src/tests.rs:58:5:
assertion `left == right` failed
left: "hello world\n[00:08:01:896 - 7FA1CA910640]: warning: a module with WASI apis should be either a command or a reactor\n"
right: "hello world\n" |
Signed-off-by: jiaxiao zhou <[email protected]>
|
Also, it doesn't seem like it runs on Windows: https://github.com/containerd/runwasi/actions/runs/11692971119/job/32563482903?pr=716#step:8:167 |
Signed-off-by: jiaxiao zhou <[email protected]>
Signed-off-by: jiaxiao zhou <[email protected]>
Signed-off-by: jiaxiao zhou <[email protected]>
|
Yes, that's because WAMR enforces a strict application ABI check. Every wasm32-wasi .wasm should be classified as either a command or a reactor. For your case,
|
Follow up on the work done by #508 and #642. The runtime execution
"thread signal env initialized failed"error was resolved by the upstream Wamr SDK and thus I used the latest sdk to re-build the wamr shim.Now it actually worked!
TODO