-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
rust-lld links WebAssembly imports during compilation #56309
Comments
Thanks for the reprot! This is due to the fact that |
jonas-schievink
added
A-linkage
Area: linking into static, shared libraries and binaries
O-wasm
Target: WASM (WebAssembly), http://webassembly.org/
labels
Jan 27, 2019
Mark-Simulacrum
added a commit
to Mark-Simulacrum/rust
that referenced
this issue
Dec 19, 2019
…=eddyb Fix handling of wasm import modules and names The WebAssembly targets of rustc have weird issues around name mangling and import the same name from different modules. This all largely stems from the fact that we're using literal symbol names in LLVM IR to represent what a function is called when it's imported, and we're not using the wasm-specific `wasm-import-name` attribute. This in turn leads to two issues: * If, in the same codegen unit, the same FFI symbol is referenced twice then rustc, when translating to LLVM IR, will only reference one symbol from the first wasm module referenced. * There's also a bug in LLD [1] where even if two codegen units reference different modules, having the same symbol names means that LLD coalesces the symbols and only refers to one wasm module. Put another way, all our imported wasm symbols from the environment are keyed off their LLVM IR symbol name, which has lots of collisions today. This commit fixes the issue by implementing two changes: 1. All wasm symbols with `#[link(wasm_import_module = "...")]` are mangled by default in LLVM IR. This means they're all given unique names. 2. Symbols then use the `wasm-import-name` attribute to ensure that the WebAssembly file uses the correct import name. When put together this should ensure we don't trip over the LLD bug [1] and we also codegen IR correctly always referencing the right symbols with the right import module/name pairs. Closes rust-lang#50021 Closes rust-lang#56309 Closes rust-lang#63562 [1]: https://bugs.llvm.org/show_bug.cgi?id=44316
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 20, 2019
…=eddyb Fix handling of wasm import modules and names The WebAssembly targets of rustc have weird issues around name mangling and import the same name from different modules. This all largely stems from the fact that we're using literal symbol names in LLVM IR to represent what a function is called when it's imported, and we're not using the wasm-specific `wasm-import-name` attribute. This in turn leads to two issues: * If, in the same codegen unit, the same FFI symbol is referenced twice then rustc, when translating to LLVM IR, will only reference one symbol from the first wasm module referenced. * There's also a bug in LLD [1] where even if two codegen units reference different modules, having the same symbol names means that LLD coalesces the symbols and only refers to one wasm module. Put another way, all our imported wasm symbols from the environment are keyed off their LLVM IR symbol name, which has lots of collisions today. This commit fixes the issue by implementing two changes: 1. All wasm symbols with `#[link(wasm_import_module = "...")]` are mangled by default in LLVM IR. This means they're all given unique names. 2. Symbols then use the `wasm-import-name` attribute to ensure that the WebAssembly file uses the correct import name. When put together this should ensure we don't trip over the LLD bug [1] and we also codegen IR correctly always referencing the right symbols with the right import module/name pairs. Closes rust-lang#50021 Closes rust-lang#56309 Closes rust-lang#63562 [1]: https://bugs.llvm.org/show_bug.cgi?id=44316
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 20, 2019
…=eddyb Fix handling of wasm import modules and names The WebAssembly targets of rustc have weird issues around name mangling and import the same name from different modules. This all largely stems from the fact that we're using literal symbol names in LLVM IR to represent what a function is called when it's imported, and we're not using the wasm-specific `wasm-import-name` attribute. This in turn leads to two issues: * If, in the same codegen unit, the same FFI symbol is referenced twice then rustc, when translating to LLVM IR, will only reference one symbol from the first wasm module referenced. * There's also a bug in LLD [1] where even if two codegen units reference different modules, having the same symbol names means that LLD coalesces the symbols and only refers to one wasm module. Put another way, all our imported wasm symbols from the environment are keyed off their LLVM IR symbol name, which has lots of collisions today. This commit fixes the issue by implementing two changes: 1. All wasm symbols with `#[link(wasm_import_module = "...")]` are mangled by default in LLVM IR. This means they're all given unique names. 2. Symbols then use the `wasm-import-name` attribute to ensure that the WebAssembly file uses the correct import name. When put together this should ensure we don't trip over the LLD bug [1] and we also codegen IR correctly always referencing the right symbols with the right import module/name pairs. Closes rust-lang#50021 Closes rust-lang#56309 Closes rust-lang#63562 [1]: https://bugs.llvm.org/show_bug.cgi?id=44316
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It appears that
rust-lld
links WebAssembly imports during compilation, even though they should be only imported at runtime.Code
Cargo (stable)
Build succeeds:
but there are no imports in the compiled WASM module:
and it actually inlines some
log()
function (probably fromcompiler-builtins
).Cargo (nightly)
Build fails due to a conflict between WebAssembly import (
test.log
) andcompiler-builtins
'slog()
:Workaround
Simply changing the function name, either directly or by using
#[link_name = "xlog"]
, to avoid the conflict works around the issue, but that's obviously far from perfect.Version info
The text was updated successfully, but these errors were encountered: