Best practices for Module['buffer']?

[willcohen]

Moving WebAssembly/binaryen#5390 here.

New emscripten-specific question
It looks like my attempts to use Module['buffer'] in pre-js are ill-advised, per #18452. For environments without WebAssembly, what is the preferred method to pass an external ArrayBuffer?

I suppose I'd be happy to use the internal glue code's mechanism as well, but something about the graaljs environment seems unable right now to create a memory or wasmMemory object on its own to emscripten's satisfaction. That said, I can absolutely confirm that I can create ArrayBuffers, and that they seem truthy enough on an ad-hoc basis.

Original text from binaryen issue
In attempting to load a wasm2js-generated js file on graaljs, I hit the following error:

failed to compile wasm module: TypeError: Cannot read property 'buffer' of undefined
Execution error (PolyglotException) at <js>/asmFunc (src.js:493).
TypeError: Cannot read property 'buffer' of undefined

It's referring to these lines in the transpiled js, implying that the env.memory section is undefined.

function asmFunc(env) {
 var memory = env.memory;
 var buffer = memory.buffer;

This error occurs when using the shell environment, which I suppose graal isn't, but running the transpilation without setting an env fails with Aborted(Assertion failed: shell environment detected but not enabled at build time. Add 'shell' to -sENVIRONMENT to enable.)

Should I be using a different environment, does this mean that the shell environment needs something else to generate a WebAssembly.Memory, or does there need to be an entirely new graal environment?

[willcohen]

@sbc100
Based on #18454, does this mean that the path forward for JS-only users should be to create something in pre-js like:

var Module = {
  wasmMemory = { buffer: new ArrayBuffer() }
};

[kripken]

I think that's right but @sbc100 might be aware of something I forgot.

Note that you also need -sIMPORTED_MEMORY so that you can provide a memory like that, which will then be imported into the wasm (as opposed to the default where it is defined in the wasm).

[sbc100]

Agreed, I would have thought you wouldn't actually need this at all, unless you explicitly opt into `-sIMPORTED_MEMORY`. In the default configuration the memory should be created by the wasm (or the transpiles wasm2js) automatically. Did you have code that used to work prior to #18454 and/or #18452? If so, can you share what it looked like exactly? I'd like to avoid breaking folks if we can.

[willcohen]

Other way around, actually -- no working examples. I was trying to figure out why graaljs kept insisting that memory.buffer was undefined, which led me to try providing an imported one, assuming the issue was one of me using the wrong flags or needing to stick some pre-js in. Based on #18452 I tried replacing the uses of env.memory and memory.buffer inside the generated -O0 code itself with a direct usage of Memory['wasmMemory'] and it loaded successfully with graal, at least with emscripten 3.1.24 (stuck there for now because of LLVM 14).

I've gone ahead and backported #18452 and #18454 locally and anything else that touched runtime_init_memory since 3.1.24 to see if that clears it up, rather than trying to trace the older code more. With that, missingGlobal is now triggered on buffer -- looks like what @kripken had noted in WebAssembly/binaryen#5390. graaljs is falling through the cracks between shell and however emscripten expects it to behave for wasmMemory.

[willcohen]

Problem solved. #18452 and #18454 indeed solve the problem, suggesting that this is similar to #17842. That wasn't clear to me yesterday because in trying to debug I'd added 'wasmMemory' to EXPORTED_RUNTIME_METHODS, which needed to be removed for the missingGlobal to go away. Many thanks and sorry for the bother.