Miscompilation of compiler_builtins for wasm32-unknown-emscripten target

[hoodmane]

To get around the problem in #92738, I manually remove the lib.rmeta files from the .rlib files. Then linking succeeds except that compiler_builtins-[...].compiler_builtins.[...]-cgu.1.rcgu.o has invalid wasm. If I remove also compiler_builtins-[...].compiler_builtins.[...]-cgu.1.rcgu.o, then linking succeeds and the code works correctly as long as it does not attempt to use any of the symbols that are defined in compiler_builtins-e79221a6cfe3d845.compiler_builtins.76620b52-cgu.1.rcgu.o (in that case it crashes of course).

If I try to validate it, I get:
wasm-validate compiler_builtins-e79221a6cfe3d845.compiler_builtins.76620b52-cgu.1.rcgu.o --enable-all

compiler_builtins-e79221a6cfe3d845.compiler_builtins.76620b52-cgu.1.rcgu.o:00007dc: error: type mismatch in call, expected [i32, i64, i64, i32] but got [... i64, i64, i64, i64]
compiler_builtins-e79221a6cfe3d845.compiler_builtins.76620b52-cgu.1.rcgu.o:00007f3: error: type mismatch in call, expected [i32, i64, i64, i32] but got [... i64, i64, i64, i64]
compiler_builtins-e79221a6cfe3d845.compiler_builtins.76620b52-cgu.1.rcgu.o:0000827: error: type mismatch in function, expected [] but got [i32, i32]
compiler_builtins-e79221a6cfe3d845.compiler_builtins.76620b52-cgu.1.rcgu.o:0000872: error: type mismatch in implicit return, expected [i32] but got [i64]

If I use

ar -d target/wasm32-unknown-emscripten/debug/deps/libcompiler_builtins-e79221a6cfe3d845.rlib compiler_builtins-e79221a6cfe3d845.compiler_builtins.76620b52-cgu.1.rcgu.o

and then rerun the linker command it successfully links.

Versions of tools

$ emcc --version
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 2.0.16

$ wasm-ld --version
LLD 13.0.0 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.jparrowsec.cn-llvm-llvm--project ad8010e598d9aa3747c34ce28aa2ba6de1650bd4)

$ rustc +nightly --version
rustc 1.59.0-nightly (f1ce0e6a0 2022-01-05)

I am compiling with RUSTFLAGS="-C link-arg=-s -C link-arg=SIDE_MODULE=1 -C relocation-model=pic -C target-feature=+mutable-globals".

I am compiling lib.rs which looks as follows:

lib.rs

#[no_mangle]
pub extern "C" fn main() -> i32 {
    0	
}

and my Cargo.toml is:

Cargo.toml

[package]
name = "rust_test"
version = "0.1.0"
edition = "2021"

[lib]
name = "rust_test"
crate-type = ["cdylib"]

In the above case, the code is so simple that it doesn't use any of the missing symbols. However, if we add a function like:

#[no_mangle]
fn test(a: Vec<String>) {
    for string in a {
        println!("{}", string)
    }
}

then linking succeeds but if we try to call test it will crash due to missing symbols (related to deref of string).

[hoodmane]

Perhaps we could do something as simple as compile a trivial rust program for wasm32-unknown and find the corresponding object files in the wasm32-unknown build artifacts, then replace the bad object files in the wasm32-emscripten build with the good object files from the wasm32-unknown target. I bet that'd work.

Failing that, the next thing to do would be to get out the wasm binary toolkit, the wasm binary spec, and a hex editor and track down the encoding errors in these files.

[hoodmane]

Closed as fixed, either by changes to Rust or to changes to Emscripten or both.