Emterpreter data not embedded in WASM

[curiousdannii]

If you're compiling to WASM with the Emterpreter, the Emterpreter data is not embedded within the WASM and is either left as a standalone file, or embedded as an array in the JS.

The WASM spec allows you to have multiple data sections, and the Emterpreter data is just being set in the main heap, so it should be possible to have it embedded in the WASM, right?

Also, the helpful error for when you forget to load the data file Assertion failed: bad emterpreter file in -O0 turns into the much less clear failed to asynchronously prepare wasm: RuntimeError: remainder by zero in -O3.

[kripken]

Good idea, this would be useful to do.

About those errors, do you have a testcase showing them?

[curiousdannii]

What form of testcase would be most useful for you?

I could very easily make two branches to checkout of my moderate sized project with the -O setting changed, and then all you'd need to do is run make, if that would be enough.

[kripken]

Yeah, that would be enough. Just as long as it's a simple checkout + run make (i.e. I don't need to install a build system or other tools).

[curiousdannii]

I was able to make a minimal test case: https://gist.github.com/curiousdannii/07f1d750226befd4cbf6d858f204ac94

The -O3 error message is different however: failed to asynchronously prepare wasm: RuntimeError: memory access out of bounds

[kripken]

I tried to debug this in the spidermonkey shell, where the error is different. It works without the emterpreter file, but with it, it fails. Looks like it hits this assertion:

  var bytecodeFile = Module['emterpreterFile'];
  assert(bytecodeFile instanceof ArrayBuffer, 'bad emterpreter file');

Looking in the docs, it says

src/settings.js:                            // When emitting HTML, we automatically generate code to load this file and set it to Module.emterpreterFile. If you
src/settings.js:                            // emit JS, you need to make sure that Module.emterpreterFile contains an ArrayBuffer with the bytecode, when the code loads.

So looks like the user needs to set that file, since we compiled to JS and not HTML. Maybe that's the problem you were hitting?

[curiousdannii]

So looks like the user needs to set that file, since we compiled to JS and not HTML. Maybe that's the problem you were hitting?

Yeah, but the issue is that the explicit error message is shown in -O0, but in -O3 (I think actually -O1+) the error message isn't shown, and some other WASM loading error is shown.

Or is this by design - error messages like this are only meant to be shown when assertions are on? If so, then I think missing file errors like this deserve being made normal errors and shown even when assertions are off. FWIW the memory loader throws normally.

If #5104 was resolved through a centralised loading system then we wouldn't need to have multiple places checking and throwing errors. :)

[kripken]

I agree, an error like that should be handled even when assertions are off. We should replace the assert on it with a check and call of abort, PR would be welcome.

[curiousdannii]

According to the WASM spec this may not be possible yet:

In the current version of WebAssembly, at most one memory is allowed in a module. Consequently, the only valid memidxmemidx is 00.

[kripken]

It's true we can't embed it as a new memory, but we can enlarge the existing single memory and add it into there. We also need to update the static-bump stuff so the compiler knows that we are using more memory statically.

[curiousdannii]

I'd be interested in working on this, but I think it will probably end up being beyond me.

I took a look, and I couldn't see any sort of general purpose wasm embedder.

Two options I can see:

1. Alter asm2wasm to take extra options for the emterpreter file and offset, and then add the extra memory segment
2. Create a full wasm file with basically nothing in it except the emterpreter memory, and then merge them

I think the first is probably better, but it would require me to dig into the binaryen source, whereas the second may potentially be doable just in emcc.py.