Rough sketch for a syscall API for argv/argc and exit status about wasi-libc HOT 9 CLOSED

@bjfish the function being named "main" is the convention, isn't it? whatever is running the wasm can just assume that is the main entry point by convention.

from wasi-libc.

• I'm not 100% sure but I don't think this is the intended purpose of the wasm start function. Using it this way would mean that main() would get called when the main module is instantiated.
• Where does the argv data ultimately come from? Unless I'm missing something, it seems better for the module to ask the module from which it's importing where the argv data is, instead of setting it.

from wasi-libc.

I'm not 100% sure but I don't think this is the intended purpose of the wasm start function. Using it this way would mean that main() would get called when the main module is instantiated.

That's a good point. I've tweaked the wording a little, but let me also explain here: Calling main from the wasm start function isn't the only way to do it, but for purely command-line-oriented programs, I think it is a natural way to do it. The important aspect here is that we don't want to rely on the entrypoint (whatever it is) having arguents or return values.

Where does the argv data ultimately come from? Unless I'm missing something, it seems better for the module to ask the module from which it's importing where the argv data is, instead of setting it.

The argv data comes from whatever entity satisfies these imports. In a command-line-oriented wasm runner, these might be provided by the runner itself. In a browser, there might be a polyfill module providing a command-line-environment to run in. Other environments could decide how to resolve these symbols in whatever way makes sense in their contexts.

As for pointing the module to where the argv data is rather than copying it in, the difficulty is that Wasm programs by design can't refer to data they haven't been explicitly given access to.

from wasi-libc.

Where does the argv data ultimately come from? Unless I'm missing something, it seems better for the module to ask the module from which it's importing where the argv data is, instead of setting it.

The argv data comes from whatever entity satisfies these imports. In a command-line-oriented wasm runner, these might be provided by the runner itself. In a browser, there might be a polyfill module providing a command-line-environment to run in. Other environments could decide how to resolve these symbols in whatever way makes sense in their contexts.

As for pointing the module to where the argv data is rather than copying it in, the difficulty is that Wasm programs by design can't refer to data they haven't been explicitly given access to.

I see, so the module runner is responsible for filling the argv data when the module calls store_argv_data. The naming was a bit confusing for me, since by "store" I thought that meant it was sending (storing) the pointer to the module runner.

from wasi-libc.

It would be nice if there was some convention regarding calling a main() or init() but calling this from start has this limitation? WebAssembly/design#1160

from wasi-libc.

@rianhunter Yes, I think a "main" function being the entry point would be a good convention for a wasm runtime. It'd be nice to have an option to override this via configuration as well.

from wasi-libc.

Would that pass in cli arguments as parameters like emscripten does? Or would imported functions be used to get the cli arguments?

from wasi-libc.

@lachlansneff I think the way emscripten does this is by generating glue code (shims) which call it’s own wasm syscall/runtime API. In the short term, I think imported functions could be used directly but hopefully future glue code would adopt the new reference syscall API.

from wasi-libc.

This design for command-line arguments is now subsumed by the WASI proposal; see the __wasi_args_* functions in the API.

from wasi-libc.