bytecodealliance / javy

JS to WebAssembly toolchain
Apache License 2.0
2.16k stars 103 forks source link

Support a WASI reactor target #587

Open andrewmd5 opened 7 months ago

andrewmd5 commented 7 months ago

Operating system: macOS Processor architecture: M1 (arm64) Rust version: not applicable Javy version: latest

Problem

WASI/WASM ceremony is all over the place depending on what compiler produced the module. Most expect _start or _initialize to be called prior to any exported functions being invoked.

In the case of modules produced by Javy, if _start is called any subsequent calls to exported functions will fail with wasmtime reporting they’re unreachable.

If I remove my calls to _start then I can call into my exported functions without issue.

saulecabrera commented 7 months ago

Javy-generated modules, are WASI-compliant by default. More concretely, Javy-generated modules are Commands, which according to the WASI specification:

A Command has a "main" function, and when this function returns the program terminates.

The main function referenced in the specification is the exported _start function; in that sense, calling any other function after calling _start will result in a panic. In theory we could make Javy modules be configurable (either a Command or Reactor) if that's something that you need for your use-case.

andrewmd5 commented 7 months ago

Right, I figured that was the case. The reason for my issue is because if we look at say TinyGo's WASM/WASI target, it requires you to call _start before calling any other methods and in reality behaves like a reactor even though it is a command module (they're currently working on a reactor compile target.)

Why this is relevant is my use-case loads extensions written in any programming language which are compiled to a WASI module, and we have to workaround and support the various calling conventions and ceremony each compiler requires since everyone is fast and loose with the standards.

So, with that being said, a reactor target would be great for Javy so we can have setup code and still call exported functions.

saulecabrera commented 7 months ago

If you're willing to work on a PR to add this functionality, I'd be happy to review it.