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

Fix handling of wasm import modules and names #67363

Merged
merged 1 commit into from
Dec 20, 2019

Conversation

alexcrichton
Copy link
Member

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 #50021
Closes #56309
Closes #63562

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
@rust-highfive
Copy link
Collaborator

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 16, 2019
@eddyb
Copy link
Member

eddyb commented Dec 17, 2019

@bors r+

@bors
Copy link
Contributor

bors commented Dec 17, 2019

📌 Commit aa0ef5a has been approved by eddyb

@bors
Copy link
Contributor

bors commented Dec 17, 2019

🌲 The tree is currently closed for pull requests below priority 100, this pull request will be tested once the tree is reopened

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 17, 2019
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request 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
bors added a commit that referenced this pull request Dec 19, 2019
Rollup of 9 pull requests

Successful merges:

 - #67321 (make htons const fn)
 - #67328 (Remove now-redundant range check on u128 -> f32 casts)
 - #67333 ([mir-opt] Fix `Inline` pass to handle inlining into `box` expressions)
 - #67354 (Fix pointing at arg when cause is outside of call)
 - #67363 (Fix handling of wasm import modules and names)
 - #67382 (Remove some unnecessary `ATTR_*` constants.)
 - #67389 (Remove `SO_NOSIGPIPE` dummy variable on platforms that don't use it.)
 - #67393 (Enable opting out of specific default LLVM arguments.)
 - #67394 (Remove outdated references to @t from comments)

Failed merges:

r? @ghost
Centril added a commit to Centril/rust that referenced this pull request 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 pull request 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
bors added a commit that referenced this pull request Dec 20, 2019
Rollup of 5 pull requests

Successful merges:

 - #64588 (Add a raw "address of" operator)
 - #67031 (Update tokio crates to latest versions)
 - #67131 (Merge `TraitItem` & `ImplItem into `AssocItem`)
 - #67354 (Fix pointing at arg when cause is outside of call)
 - #67363 (Fix handling of wasm import modules and names)

Failed merges:

r? @ghost
@bors bors merged commit aa0ef5a into rust-lang:master Dec 20, 2019
@alexcrichton alexcrichton deleted the wasm-import-modules branch January 6, 2020 16:51
alexcrichton added a commit to alexcrichton/wasm-bindgen that referenced this pull request Jan 6, 2020
The wasm-bindgen nightly test suite started failing recently and a
bisection shows that rust-lang/rust#67363 is the cause of this issue.
The problem happening here is that after that Rust PR duplicate imports
from the same name/module in different parts of a Rust program may now
show up as duplicate imports rather than being coalesced into one
import. This was tripping up `wasm-bindgen` which, when translating from
the wasm module to wasm-bindgen's IR, is unfortunately very
string-based.

The fix here was to detect these duplicate imports and map them all to
the same item, removing the duplicate imports.

Closes rustwasm#1929
alexcrichton added a commit to rustwasm/wasm-bindgen that referenced this pull request Jan 6, 2020
The wasm-bindgen nightly test suite started failing recently and a
bisection shows that rust-lang/rust#67363 is the cause of this issue.
The problem happening here is that after that Rust PR duplicate imports
from the same name/module in different parts of a Rust program may now
show up as duplicate imports rather than being coalesced into one
import. This was tripping up `wasm-bindgen` which, when translating from
the wasm module to wasm-bindgen's IR, is unfortunately very
string-based.

The fix here was to detect these duplicate imports and map them all to
the same item, removing the duplicate imports.

Closes #1929
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
4 participants