@Alex Crichton, @Peter Huene: I think I saw one of you comment on an issue similar to this one but I can't find it... Using the Wasmtime API, I call a _start
function that is Wasm-ified from a C function with signature int main()
.
If I useinstance.get_func("_start").get0::<()>()
(error-checking removed) I get:
failed to execute: Exited with i32 exit status 0
wasm backtrace:
0: 0x268 - <unknown>!_Exit
1: 0x2bf - <unknown>!exit
2: 0x245 - <unknown>!_start
If I use instance.get_func("_start").get0::<i32>()
I get:
failed to execute: Type mismatch in return type
Caused by:
Type mismatch, expected i32, got None
In the Wasm file, the _start
function has (type (;2;) (func))
How should I reliably handle the C-style exits? I'm guessing the first option is the type-correct way to go but how do I retrieve the exit code?
@Andrew Brown You can use (import "wasi_snapshot_preview1" "proc_exit" (func $__wasi_proc_exit (param i32)))
, and call it, to have the program exit with a specific value.
I would prefer to not have to do anything special on the C side or during the compilation to Wasm... is that possible?
If you use WASI libc, it'll handle that for you
Ok, I can switch over to using wasi-sdk... then I can just return 0;
from the int main()
function, right? Do I need to call the _start
function differently in Wasmtime?
Or better, what is the canonical way of calling the command-style, default function of a Wasm module?
Right, return 0 from main, or call exit(0)
, either works.
I would simply do what Wasmtime's run
command currently does, which is check for an exit trap: https://github.com/bytecodealliance/wasmtime/blob/main/src/commands/run.rs#L167-L175
which is the trap you're getting from the first snippet of yours above
Ah, right! Ok, let me try that
There was this related discussion earlier: https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/Behavior.20differences.20between.20wasmtime.20runtime.20and.20library/near/216390905
Which I just realized I left Till hanging :)
Thanks for the link, that is the conversation that I read a while back but couldn't place (I thought it was in a GitHub issue perhaps)
Last updated: Nov 22 2024 at 16:03 UTC