wasi-sdk: unexpected false: Bulk memory operation (bulk memory is disabled)
When upgrading from SDK 15 to 16, I’m running into the following problem whilst compiling a c file:
"/usr/bin/wasm-ld" -m wasm32 -L/share/wasi-sysroot/lib/wasm32-wasi/llvm-lto/14.0.4 -L/share/wasi-sysroot/lib/wasm32-wasi /share/wasi-sysroot/lib/wasm32-wasi/crt1-reactor.o --entry _initialize --export=malloc --export=free --export=lodepng_decode32 --export=lodepng_encode32 --strip-all /tmp/lodepng-67f409.o -lc /usr/lib/clang/14.0.4/lib/wasi/libclang_rt.builtins-wasm32.a -o lodepng.wasm
"/usr/bin/wasm-opt" lodepng.wasm -Oz -o lodepng.wasm
[wasm-validator error in function 10] unexpected false: Bulk memory operation (bulk memory is disabled), on
(memory.copy
(local.get $0)
(local.get $1)
(local.get $2)
)
[wasm-validator error in function 11] unexpected false: Bulk memory operation (bulk memory is disabled), on
(memory.fill
(local.get $0)
(local.get $1)
(local.get $2)
)
Fatal: error validating input
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
This is the command I’m running:
clang --sysroot=/share/wasi-sysroot --target=wasm32-unknown-wasi -flto -Oz -o lodepng.wasm -DLODEPNG_NO_COMPILE_DISK -DLODEPNG_NO_COMPILE_CPP -mexec-model=reactor -fvisibility=hidden -Wl,--export=malloc,--export=free,--export=lodepng_decode32,--export=lodepng_encode32,--strip-all -v -- lodepng/lodepng.c
Here is a Dockerfile that can be used to reproduce this. As can be seen, this used to work with SDK 15:
https://github.com/LinusU/cwasm-lodepng/commit/3d9ab53031d13bec662ffa8f50b57ac49d106e6a
I’ve tried to work around this for quite a while, but couldn’t find anything that worked. I’ve tried passing -mbulk-memory
to clang, which seems to change the error slightly, but still doesn’t work. Any help, or pointers on what to Google, would be much appreciated!
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 20 (13 by maintainers)
The features section mostly exists tools further down the pipeline to read (e.g. wasm-opt). I don’t know of any other reason to keep it around… I guess a node runtime could use it to set certain node flags (i.e. enable certain experimental features).
The wasm binary generated by the linker should contain features section which contains bulk memory.
I think the correct fix here is to pass
--detect-features
to wasm-opt. @tlively should find a way to make that the default? It seems like it should the default and we could have an opt of with something like--ignore-features
or--override-features
?