I am currently trying to create an executable WebA...

# webassembly

[Marc]

I am currently trying to create an executable WebAssembly project for Node and set up a project that uses Multiplatform version 1.8.20-dev-5802 . I managed to get it working in that I get an .mjs file and a .wasm file, but when I try to execute the .mjs file with Node 19.4.0 with a completely empty main function, the execution fails with the following message:
CompileError: WebAssembly.Module(): Compiling function #13:"kotlin.text.checkRadix" failed: Invalid opcode 0xe3 @+9238
When I try to open the produced file in an online WASM to WAT converter, it also fails. How can there be an invalid opcode? Am I missing any flags that I have to enable in Node? I am currently using --experimental-wasm-eh, --experimental-wasm-typed-funcref and --experimental-wasm-gc . From what I have seen after a quick Google search, the opcode 0xe3 doesn't seem to be valid currently anyways, not even when considering all active proposals.

[sdeleuze]

This is expected due to WebAssembly GC evolution, with Kotlin/Wasm 1.8.20 you need Node 20 (canary).

You can install it with:

NVM_NODEJS_ORG_MIRROR=<https://nodejs.org/download/v8-canary> nvm install v20.0.0-v8-canary202212266b2b946a63
nvm use v20.0.0-v8-canary202212266b2b946a63

And/or configure your build like https://github.com/skuzmich/kotlin-wasi-bindings-experiments/blob/main/build.gradle.kts

[Marc]

That seems to work, thanks. The repository you linked also seems very interesting, it seems to expose WASI calls to Kotlin? I was thinking if it would be possible to do it the other way around. Instead of designing your Kotlin programs to use these WASI calls, would be maybe be possible to compile a WASM program normally and replace the JS glue code with WASI calls from within the WASM executable, preferrably also written in Kotlin? That would require the names of those imported JS functions to be stable of course, which they don't really look like they are...

[sdeleuze]

Glad it works. About WASI I am doing upcoming development on https://github.com/sdeleuze/kowasm.

I am not sure what is your use case for what you describe for WASI, could you ellaborate?

[Svyatoslav Kuzmich [JB]]

Instead of designing your Kotlin programs to use these WASI calls, would be maybe be possible to compile a WASM program normally and replace the JS glue code with WASI calls from within the WASM executable, preferrably also written in Kotlin? That would require the names of those imported JS functions to be stable of course, which they don’t really look like they are...

At some point, would would likely have a version of stdlib without JS, with WASI imports only.

[sdeleuze]

Ah ok, that was about that, so yeah this would be the best outcome.

[sdeleuze]

Distinct API is just a intermediate step to move forward.

[Marc]

I am not sure what is your use case for what you describe for WASI, could you ellaborate?

I am trying to compile a standalone WASM binary that I can run externally without any JS glue, which seems like is not really currently possible... But that's why I am asking if there are any ugly hacks to do it anyways 😄

[Marc]

A version of the standard library without JS would be a dream, but is that something that is being planned right now?

[Svyatoslav Kuzmich [JB]]

It is planned. Also, having a non-JS Wasm runtime with GC support (or progress in this direction) would deficiently bump the priority of non-JS stdlib on our side.

[sdeleuze]

Yep I discussed that with Wasmtime team at some point but https://github.com/bytecodealliance/wasmtime/issues/5032 require significant effort so no short term plans. Another way to move forward would be https://github.com/WebAssembly/binaryen/issues/4590.

[Marc]

I assume that it is implemented in Node because it reuses V8's GC? It's a shame that the current non-JS runtimes don't at least have stub implementations available as far as I can tell. Even if it used a bump allocator or something that never frees the memory, one could at least run and test simple programs on there.

I assume that Kotlin/Native has to ship a GC though, would it be possible to reuse that one by compiling it to WASM as well?

[sdeleuze]

Yep that's the reason. Kotlin/Native Wasm support with GC is a dead end and will be removed, Kotlin/Wasm with GC is the way to move forward for a lot of reasons.

[sdeleuze]

Short term this is a pain but a great bet on the future.

[sdeleuze]

Once GC will be enabled by default on all browser and once Wasmtime or another non JS WASI runtime ship support for GC, that will be amazing.

[Marc]

I have never tried using the WASM target for Kotlin/Native so I wasn't aware that the idea of shipping a GC has been tried before... It sounded very complicated anyways but I thought that the Kotlin devs aren't above shipping complicated software to work around host limitations as that's kind of their hole thing...

[Marc]

But as long as it's possible to execute it at all using Node, I'm happy. My idea of replacing the JS glue code calls with WASM code to get standalone binaries probably is a bad idea anyways, right?

[sdeleuze]

I think that will be doable via migrating to using Kotlin/Wasm standard libraries and other multiplatform libraries once supported (or using KoWasm when mature enough in the interim).

[sdeleuze]

So not a bad idea but won't be automatic IMO

[Marc]

I was looking at this mapping in the JS code and technically you should be able to translate them to WASI calls, right? The only thing that I am unsure about is that these look like compiler implementation details that might change at any time.

[Svyatoslav Kuzmich [JB]]

These is implementation detail, and can change, yes. Maybe someday we’ll make these names stable, but it is not a priority. It is better to use this JS file as-is for now (all Wasm GC runtimes currently support JS, so this shouldn’t be a problem), and wait for non-JS stdlib.

[Marc]

Okay, thanks!

[Marc]

I have made some progress implementing a simple API for testing some WASM features, but I'm having some trouble opening sockets. If I understood correctly you need to pass a file descriptor handle and register it in the preopens configuration section somehow but what exactly are you supposed to write there? I tried putting IP addresses with and without ports in there but all I get are UVWASI_ENOENT errors.

[sdeleuze]

Not supported yet https://github.com/nodejs/uvwasi/issues/183

[Marc]

Oh, that makes a lot of sense then. I couldn't find anything about that on Google and I didn't think to check the issues. Are there any other parts of the WASI spec that are unimplemented?