Using wasm binaries generated by Golang (dealing with single exported function)

[kyegupov]

I'm working on a project to build substrate-compatible Wasm modules using Go language.
We already have a working parity serialization implementation (https://github.com/Joystream/parity-codec-go) and the next step was to try and build some Wasm modules and use them via Substrate's WasmExecutor.

But, the world is full of suffering, and Go's Wasm support is quite quirky. Apparently (as per golang/go#25612), the only exported function ever is "main" which is renamed to "run" but still accepts only a list of strings ("argv").

There are 2 ways of solving this problem: first, fix/augment the Go Wasm compiler to enable exporting other functions in the generated binaries; second, try to use the "run" function as a dispatch one to expose other arbitrary functions. This, in practice, will require not only some clever hacking in the Go code, but also patch the WasmExecutor to catch this special case and adapt to it.

I'm wondering, have anyone ever looked into this?

[pepyakin]

I'm not familiar with Go, but I think it should be able of producing dynamic libraries (i.e. those without main and with multiple export function), and the problem sounds like just a deficiency of the current compiler.

I would really want to avoid teaching WasmExecutor of another way of dispatch in order to not add additional maintanance burden.

That said, there might be another option: write an instrumentation pass that takes a wasm binary and creates exported functions (such as execute_block) which decode parameters, pass them to run function. This sounds terribly inefficient, but should do the job for the current time without adding a burden to WasmExecutor.

[gavofyork]

I presume that answers this question. Please reopen if more info needed.