Return value from wasm module via WASI

[jendrikw]

Is your feature request related to a problem? Please describe.
I have a WebAssembly file compiled from a simple C++ program. I would like to get the return value from main. I am calling the function via wasm.start()

Describe the solution you'd like
start() should return the value from _start() and/or __wasi_unstable_reactor_start.

Describe alternatives you've considered
The WASI object could also store the return value and make it available via a getter function, but I think the solution via the return value cleaner.

[devsnek]

those functions don't have a return value.

[jendrikw]

Oh, I somehow thought they did. Could there be an alternative way?

[devsnek]

what are you trying to achieve?

[jendrikw]

I'm trying to use this simple C program that detects if a number is even:

#include <stdlib.h>

#define WASM_EXPORT __attribute__((visibility("default")))

WASM_EXPORT
int main(int argc, char *argv[]) {
  char *rest;
  long i = strtol(argv[1], &rest, 10);
  return i % 2;
}

I compiled it with wasi-sdk. It works fine when running with wasmtime and I get the intended return value. I expected it to be usable with node. Or have I misunderstood something?

[devsnek]

@jendrikw if main returns non-zero it will exit the whole node program. kind of a weird design atm.

also fwiw, you don't need to set the visibility of main (it shouldn't be exported anyway)

@cjihrig perhaps we should have better behaviour for when __wasi_proc_exit is called?

[devsnek]

also this is basically what _start does:

void _start(void) {
  int r = main();
  if (r != 0) { __wasi_proc_exit(r); }
}

[guybedford]

Yeah this definitely seems odd - can start just not return the code directly?

[devsnek]

_start is doing the correct thing. The odd thing is that we don't scope __wasi_proc_exit to the WASI instance.

[cjihrig]

__wasi_proc_exit() terminates the process unconditionally because if it doesn't, the result will be a failed assertion in the wasm runtime (__wasi_proc_exit() is not allowed to return).

[guybedford]

Right, but there is no reason wasi.start() can't return the exit code that __wasi_proc_exit() stores as a side effect.

[cjihrig]

I agree, and that would be preferable. But that's not currently in our control.

[guybedford]

Can you clarify why that is the case? wasi.start() is very much a Node.js-specific API?

[devsnek]

@cjihrig indeed... i'm just saying it should not exit the node process. for the moment we can throw an exception, since wasm can't catch them yet.

@guybedford __wasi_proc_exit can happen at any point, we should probably represent it as some sort of event, not a return value.

[cjihrig]

@guybedford wasi.start() just calls into wasm here. Once inside of wasm, there is an eventual call to __wasi_proc_exit() (implemented as uvwasi_proc_exit() in node). That exits the process in C code. If __wasi_proc_exit() returns, there will be a failed assertion, that is also out of our control.

I think the proper fix would need to happen in the wasi-libc. We could also try @devsnek's suggestion of throwing an exception (by overwriting the __wasi_proc_exit() with JavaScript) in the short term.