wasm-emscripten-finalize does not escape characters

[dalcde]

For example, it generates invalid json for the following wasm file:

(module (import "env" "\"" (func $foo)))

[dalcde]

It appears to escape .wat files correctly but not .wasm files. Perhaps it is because the string is already escaped in .wat and the code just dumps it as is?

[sbc100]

Do you have examples of clang-generated wasm files that contain such things? wasm-emscripten-finalize is designed to be run by emscripten on the output of wasm-ld, which I don't think allows for symbols names that start with ".

How did you encounter this issue?

[dalcde]

I encountered this issue when compiling essentially anything with rust's wasm32-unknown-emscripten target. The issue occurs for any symbols that contain " anywhere.

[sbc100]

Hmm... I didn't realize " was valid in an llvm symbol name, does the actual symbol name contain this character or is it just in the demanded version? Would you mind attaching the an object file containing such a symbol?

[sbc100]

(or a .ll or .bc file for that matter)

[dalcde]

I've attached a tar.gz'ed object file (because github doesn't like me uploading .o files). It comes from Rust's stdlib's alloc crate.

alloc.tar.gz

[sbc100]

Ah I see the problem. All the symbols that contain " are coming from __invoke imports, which are generated by EmscriptenSjLj pass (https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp).

In that past binaryen would be in charge or lowering those names to something that emscripten understands, but that recently started happening on the llvm side: https://reviews.llvm.org/D88697, so the code that does it on the binaryen side was removed.

So basically your object file was produced with an old(er) version of llvm and fed to a recent version of binaryen (I think).

@tlively will have recommendations on how to use rust+emscripten and have all the versions line up.

[sbc100]

../emsdk/upstream/bin/llvm-nm alloc-38821dae73c49cdd.alloc.f4fleb6s-cgu.0.rcgu.o | grep \"
         U __invoke_i1_{}*_[3xi32]*_%"type0x7fd06fd533e0"*
         U __invoke_void_%"type0x7fd064014e50"*_i8*_i8*
         U __invoke_void_%"type0x7fd064b20ee0"*_{i8*.i32}*
         U __invoke_void_%"type0x7fd06fd526c0"*_i32
         U __invoke_void_[0xi8]*_i32_i32_i32_%"type0x7fd0645a9820"*
         U __invoke_void_[0xi8]*_i32_{}*_[3xi32]*_%"type0x7fd0645a9820"

These symbols would not exist with new versions of llvm.

[sbc100]

Since you are not the first person to hit this issue I think we should at a clear warning to binaryen.

[sbc100]

I think we should have wasm-emscripten-finalize error out with a link to an FAQ if it detects an old-style __invoke.

[tlively]

@dalcde Using Emscripten 1.39.20 is most likely to work correctly with recent versions of Rust because their LLVM versions are the most similar. As Rust updates its version of LLVM, the matching version of Emscripten will change. Unfortunately there aren't great docs for this, but you can check the current best Emscripten version for nightly Rust by looking at https://github.com/rust-lang/rust/blob/master/src/ci/docker/scripts/emscripten.sh.