Binaryen as WASM module itself?

[marad]

I'd love to use binaryen from Java. I've even started preparing a wrapper, which is kinda painful since I've had to generate Windows DLL by tweaking cmake.

Then it hit me - it would all be solved by having binaryen be a wasm module as well, since there are solutions to run WASM from Java.

Is something like this possible?

[tlively]

Yes, and it's even supported today. If you compile the binaryen_wasm target, you'll get a Wasm module that exports Binaryen's C API as well as a JS wrapper providing an idiomatic JS API on top of it. You could always discard the JS and reuse the Wasm module directly, though.

[tlively]

@kripken, do you know what the best set of flags to use here is?

[kripken]

--profiling or --profiling-funcs will disable name minification.

[marad]

Nice, I'll definately check it out. I suspect the functions are IO functions. I'll probably also try compiling with in-memory FS to have less of them to integrate.

[stephanos]

@marad did you ever get all of that to work? if you did and could share any insights into what remaining steps you had to take to make it work end-to-end, I'd appreciate it!

[marad]

@stephanos I did not work on this much further unfortunately, but I would like to try again in some time. What I'm planning on doing is on top of adding --profiling and --profiling-funcs I remember I saw one option to use in-memory FS. I suppose (haven't checked that) this could result in the module requiring a memory block to work with instead of importing all the FS functions.

Then I'd take a look at what other imports it needs and improvise ;)

If you try this, let me know how it went. Maybe it would be sufficient to use it this way.

[marad]

I've got some time today to fiddle with this and I must say that binaryen is trying hard not to get compiled to basic WASM module ;)

I've made quite a few variations of the CMakeLists.txt but the most imortant ones seem to be:

• removing the "-sSINGLE_FILE"
• setting set(CMAKE_EXECUTABLE_SUFFIX ".wasm") before add_executable(binaryen_wasm...
• adding target_link_libraries(binaryen_wasm "-sSIDE_MODULE=2")

This gets me a WASM file without any JS file, and now I can see the names of the functions.

It's not clear to me if that is a pure WASI since there are functions like malloc but also invoke_viiiiiiii which seem like those that were generated glue-code from JS.

  ...
  (import "env" "__cxa_atexit" (func $__cxa_atexit (type 6)))
  (import "env" "__cxa_begin_catch" (func $__cxa_begin_catch (type 2)))
  (import "env" "__cxa_end_catch" (func $__cxa_end_catch (type 16)))
  (import "env" "_ZSt9terminatev" (func $std::terminate__ (type 16)))
  (import "env" "strncpy" (func $strncpy (type 6)))
  (import "env" "malloc" (func $malloc (type 2)))
  (import "env" "pthread_self" (func $pthread_self (type 5)))
  (import "env" "free" (func $free (type 1)))
  (import "env" "posix_memalign" (func $posix_memalign (type 6)))
  (import "env" "__cxa_allocate_exception" (func $__cxa_allocate_exception (type 2)))
  (import "env" "invoke_viiiiiiii" (func (;108;) (type 67)))
  ...

@stephanos FYI ☝️

[marad]

Also for future reference:

• emcc options
• emcc settings

[kripken]

To avoid the invokes, enable wasm exception handling instead of emscripten:

https://emscripten.org/docs/porting/exceptions.html#webassembly-exception-handling-based-support

Not all VMs support it yet, but it is the only way to use C++ exceptions without emscripten's invoke_* imports.

[stephanos]

@marad Thanks for the update! I won't get to try this for another couple of weeks, but I'm excited to now!