binaryen

binaryen copied to clipboard

I'm seeing this with quite a lot of wasm64 tests in emscripten:

wasm-opt: /usr/local/google/home/sbc/dev/wasm/binaryen/src/wasm.h:715: T *wasm::Expression::cast() [T = wasm::Const]: Assertion `int(_id) == int(T::SpecificId)' failed.
emcc: error: '/usr/local/google/home/sbc/dev/wasm/binaryen-out/bin/wasm-opt --memory64-lowering --strip-producers main.wasm -o main.wasm -g --mvp-features --enable-mutable-globals --enable-memory64' failed (received SIGABRT (-6))

main.zip

Seems like this is due to memory segments that are not loaded at specific contant offsets, but based off of __memory_base. I'll disable + dyanmic linking tests for now which I think are what cases this.

Reduced testcase:

;; crashes on wasm-opt -all --memory64-lowering
(module
 (import "env" "memory" (memory $mimport$0 i64 256 256))
 (import "env" "__memory_base" (global $__memory_base i64))

 (data $.data (global.get $__memory_base) "")
)

The problem seems to be here:

https://github.com/WebAssembly/binaryen/blob/f124a11ca3a40c87ab6aa4498037449584689be9/src/passes/Memory64Lowering.cpp#L101-L108

The pass normally just converts an i64 constant to an i32, but with an imported value we actually have a problem, as the Wrap64 instruction can't be used in a global location, I think? It isn't in the short list of constant instructions.

Could we change the import to be an i32? That seems like the simplest solution, but it would depend on how the JS side sends over the offset.

Yes I think that solution makes sense. In the short term I've disabled MEMORY64 + dynamic linking. Once everything else is working I'll re-enable that try that fix.