-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
rustc: Fix wasm64 metadata object files #121464
Conversation
r? @wesleywiser rustbot has assigned @wesleywiser. Use r? to explicitly pick a reviewer |
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging. |
I'll also note that if the compiler would prefer to not depend on |
☔ The latest upstream changes (presumably #121514) made this pull request unmergeable. Please resolve the merge conflicts. |
It looks like LLD will detect object files being either 32 or 64-bit depending on any memory present. LLD will additionally reject 32-bit objects during a 64-bit link. Previously metadata objects did not have any memories in them which led LLD to conclude they were 32-bit objects which broke 64-bit targets for wasm. This commit fixes this by ensuring that for 64-bit targets there's a memory object present to get LLD to detect it's a 64-bit target. Additionally this commit moves away from a hand-crafted wasm encoder to the `wasm-encoder` crate on crates.io as the complexity grows for the generated object file. Closes rust-lang#121460
6f5030f
to
646e8e7
Compare
Rebased! |
@rustbot ready |
imports.import( | ||
"env", | ||
"__linear_memory", | ||
wasm_encoder::MemoryType { minimum: 0, maximum: None, memory64: true, shared: false }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, does the memory persist into the final wasm object or can it be dropped by the linker since it's unused?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question, but this is only here to assist with detection of what kind of object it is, I believe LLD has separate logic for omitting the memory if it's not needed (although practically all rust programs will need a linear memory)
@bors r+ rollup |
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#121326 (Detect empty leading where clauses on type aliases) - rust-lang#121464 (rustc: Fix wasm64 metadata object files) - rust-lang#121681 (Safe Transmute: Revise safety analysis) - rust-lang#121753 (Add proper cfg to keep only one AlignmentEnum definition for different target_pointer_widths) - rust-lang#121782 (allow statics pointing to mutable statics) - rust-lang#121798 (Fix links in rustc doc) - rust-lang#121806 (add const test for ptr::metadata) - rust-lang#121809 (Remove doc aliases to PATH) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#121464 - alexcrichton:fix-wasm64, r=wesleywiser rustc: Fix wasm64 metadata object files It looks like LLD will detect object files being either 32 or 64-bit depending on any memory present. LLD will additionally reject 32-bit objects during a 64-bit link. Previously metadata objects did not have any memories in them which led LLD to conclude they were 32-bit objects which broke 64-bit targets for wasm. This commit fixes this by ensuring that for 64-bit targets there's a memory object present to get LLD to detect it's a 64-bit target. Additionally this commit moves away from a hand-crafted wasm encoder to the `wasm-encoder` crate on crates.io as the complexity grows for the generated object file. Closes rust-lang#121460
Relevant upstream changes: rust-lang/rust#120675: An intrinsic `Symbol` is now wrapped in a `IntrinsicDef` struct, so the relevant part of the code needed to be updated. rust-lang/rust#121464: The second argument of the `create_wrapper_file` function changed from a vector to a string. rust-lang/rust#121662: `NullOp::DebugAssertions` was renamed to `NullOp::UbCheck` and it now has data (currently unused by Kani) rust-lang/rust#121728: Introduces `F16` and `F128`, so needed to add stubs for them rust-lang/rust#121969: `parse_sess` was renamed to `psess`, so updated the relevant code. rust-lang/rust#122059: The `is_val_statically_known` intrinsic is now used in some `core::fmt` code, so had to handle it in (codegen'ed to false). rust-lang/rust#122233: This added a new `retag_box_to_raw` intrinsic. This is an operation that is primarily relevant for stacked borrows. For Kani, we just return the pointer. Resolves #3057
It looks like LLD will detect object files being either 32 or 64-bit depending on any memory present. LLD will additionally reject 32-bit objects during a 64-bit link. Previously metadata objects did not have any memories in them which led LLD to conclude they were 32-bit objects which broke 64-bit targets for wasm.
This commit fixes this by ensuring that for 64-bit targets there's a memory object present to get LLD to detect it's a 64-bit target. Additionally this commit moves away from a hand-crafted wasm encoder to the
wasm-encoder
crate on crates.io as the complexity grows for the generated object file.Closes #121460