Skip to content

Backport Wasm 64-bit table fix to 19.x #119717

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

Closed
adambratschikaye opened this issue Dec 12, 2024 · 3 comments
Closed

Backport Wasm 64-bit table fix to 19.x #119717

adambratschikaye opened this issue Dec 12, 2024 · 3 comments

Comments

@adambratschikaye
Copy link

In rustc, the wasm64-unknown-unknown target produces invalid Wasm modules due to an issue with 64-bit tables that was fixed in #107780. Would it be possible to backport that fix to the 19.x release branch so that rust can pick it up?

Here are steps to reproduce the issue with cargo/rustc:

❯ rustc +nightly --version
rustc 1.85.0-nightly (a224f3807 2024-12-09)

❯ cargo new --bin foo

❯ cd foo

❯ cargo +nightly build -Z build-std=std,panic_abort --target wasm64-unknown-unknown

❯ wasm-objdump -j Elem -x target/wasm64-unknown-unknown/debug/foo.wasm | head

foo.wasm:       file format wasm 0x1
module name: <foo-87b5668ca08bcff0.wasm>

Section Details:

Elem[1]:
 - segment[0] flags=0 table=0 count=91 - init i64=94235877441537
  - elem[94235877441537] = ref.func:3 <_ZN3foo4main17h3e4566f0ffb33d02E>
  - elem[94235877441538] = ref.func:5 <_ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17ha696e16b756653ccE>

Here we can see the init expression for the table is reading uninitialized memory.

cc @sbc100 @alexcrichton @lwshang

@llvmbot
Copy link
Member

llvmbot commented Dec 12, 2024

@llvm/issue-subscribers-lld-wasm

Author: Adam Bratschi-Kaye (adambratschikaye)

In `rustc`, the `wasm64-unknown-unknown` target produces invalid Wasm modules due to an issue with 64-bit tables that was fixed in https://github.com//pull/107780. Would it be possible to backport that fix to the 19.x release branch so that rust can pick it up?

Here are steps to reproduce the issue with cargo/rustc:

❯ rustc +nightly --version
rustc 1.85.0-nightly (a224f3807 2024-12-09)

❯ cargo new --bin foo

❯ cd foo

❯ cargo +nightly build -Z build-std=std,panic_abort --target wasm64-unknown-unknown

❯ wasm-objdump -j Elem -x target/wasm64-unknown-unknown/debug/foo.wasm | head

foo.wasm:       file format wasm 0x1
module name: &lt;foo-87b5668ca08bcff0.wasm&gt;

Section Details:

Elem[1]:
 - segment[0] flags=0 table=0 count=91 - init i64=94235877441537
  - elem[94235877441537] = ref.func:3 &lt;_ZN3foo4main17h3e4566f0ffb33d02E&gt;
  - elem[94235877441538] = ref.func:5 &lt;_ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17ha696e16b756653ccE&gt;

Here we can see the init expression for the table is reading uninitialized memory.

cc @sbc100 @alexcrichton @lwshang

@nikic
Copy link
Contributor

nikic commented Dec 12, 2024

/cherry-pick 5c8fd1e

@llvmbot llvmbot closed this as completed Dec 12, 2024
@github-project-automation github-project-automation bot moved this from Needs Triage to Done in LLVM Release Status Dec 12, 2024
@llvmbot
Copy link
Member

llvmbot commented Dec 12, 2024

/pull-request #119723

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

4 participants