Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Miscompilation of compiler_builtins for wasm32-unknown-emscripten target #93015

Closed
hoodmane opened this issue Jan 17, 2022 · 2 comments
Closed
Labels
C-bug Category: This is a bug.

Comments

@hoodmane
Copy link
Contributor

hoodmane commented Jan 17, 2022

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.com-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
Copy link
Contributor Author

hoodmane commented Apr 8, 2022

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
Copy link
Contributor Author

hoodmane commented Apr 8, 2022

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

@hoodmane hoodmane closed this as completed Apr 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

1 participant