Skip to content

Can not disable reference-types feature for wasm32 target with -C linker-plugin-lto flag #130604

Closed
Closed
Can not disable reference-types feature for wasm32 target with -C linker-plugin-lto flag#130604
Labels
C-bugCategory: This is a bug.O-wasmTarget: WASM (WebAssembly), http://webassembly.org/P-mediumMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-untriagedUntriaged performance or correctness regression.

Description

@StackOverflowExcept1on
StackOverflowExcept1on
opened on Sep 20, 2024

Code

@alexcrichton

Code is minimized as much as possible and here is a demo repository: https://github.com/StackOverflowExcept1on/wasm-builder-regression/

  • wasm-checker - simple CLI tool that passes wasm to parity-wasm parser (it does not support reference-types)
  • wasm-program - this is smart contract that panics and terminates with an error
  • wasm-project - some intermediate directory that is generated by our utility
  • check.sh source code
git clone https://github.com/StackOverflowExcept1on/wasm-builder-regression.git
cd wasm-builder-regression/wasm-project
./check.sh
    Finished `release` profile [optimized] target(s) in 8.30s

   Compiling gear-wasm v0.45.1
   Compiling wasm-checker v0.1.0 (/mnt/tmpfs/wasm-builder-regression/wasm-checker)
    Finished `release` profile [optimized] target(s) in 1.68s
     Running `/mnt/tmpfs/wasm-builder-regression/wasm-checker/target/release/wasm-checker ./target/wasm32-unknown-unknown/release/wasm_program.wasm`

Error: InvalidTableReference(128)

If I remove flag -C linker-plugin-lto, it works as described in #128511

I expected to see this happen: I can disable reference-types via -Ctarget-cpu=mvp and -Zbuild-std

Instead, this happened: there is some kind of conflict between compiler flags?

Version it worked on

It most recently worked on: nightly-2024-07-31

Version with regression

rustc +nightly-2024-08-01 --version --verbose:

rustc 1.82.0-nightly (28a58f2fa 2024-07-31)
binary: rustc
commit-hash: 28a58f2fa7f0c46b8fab8237c02471a915924fe5
commit-date: 2024-07-31
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 19.1.0

Activity

  1. StackOverflowExcept1on
    added
    C-bugCategory: This is a bug.
    regression-untriagedUntriaged performance or correctness regression.
    on Sep 20, 2024
  2. rustbot
    added
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Sep 20, 2024
  3. jieyouxu
    added
    O-wasmTarget: WASM (WebAssembly), http://webassembly.org/
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Sep 20, 2024

  4. alexcrichton commented on Sep 20, 2024

    @alexcrichton
    alexcrichton
    on Sep 20, 2024
    Member

    Thanks for the report! I'm not actually sure what's going on here. My best guess though is that wasm-ld is performing codegen on behalf of -Clinker-plugin-lto and it's not configured the same way as rustc. For example -Ctarget-cpu is a Rust compiler flag which it translates to LLVM, but this isn't passed to wasm-ld. (AFAIK there's no way to pass this flag to wasm-ld).

    The LLVM IR going into wasm-ld looks like it's correctly annotated with "target-cpu"="mvp" on functions which also perplexes me...

    Put another way, you're doing everything right here, and the bug lies somewhere in the interaction of codegen in wasm-ld and configuring LLVM with features disabled. It might be a bug in wasm-ld itself or it might be a bug in rustc. A reduction of this issue is:

    target triple = "wasm32-unknown-unknown"
target datalayout = "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20"

define void @foo(ptr %a) #0 {
  call void %a()
  ret void
}

attributes #0 = { nounwind "target-cpu"="mvp" }

    Locally I see:

    $ llvm-as wat.ll
$ wasm-ld wat.bc -o foo.wasm --no-entry --export foo 
$ wasm-tools validate -f=-reference-types foo.wasm
error: func 0 failed to validate

Caused by:
    0: zero byte expected (at offset 0x4b)

    I've opened llvm/llvm-project#109443 to see if folks have thoughts there.

  5. apiraino commented on Oct 9, 2024

    @apiraino
    apiraino
    on Oct 9, 2024
    Contributor

    WG-prioritization assigning priority (Zulip discussion).

    @rustbot label -I-prioritize +P-medium

  6. rustbot
    added
    P-mediumMedium priority
    and removed
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Oct 9, 2024
  7. Noratrieb
    removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Nov 9, 2024

  8. StackOverflowExcept1on commented on Dec 14, 2024

    @StackOverflowExcept1on
    StackOverflowExcept1on
    on Dec 14, 2024
    ContributorAuthor

    @alexcrichton this bug is also reproduced on the new target wasm32v1-none.

  9. alexcrichton commented on Dec 16, 2024

    @alexcrichton
    alexcrichton
    on Dec 16, 2024
    Member

    Can you provide reproduction steps necessary? Just saying "also reproduced on the new target" isn't too helpful at indicating what you're doing to reproduce this or what is even being reproduced.

  10. StackOverflowExcept1on commented on Dec 16, 2024

    @StackOverflowExcept1on
    StackOverflowExcept1on
    on Dec 16, 2024
    ContributorAuthor

    @alexcrichton Of course, same example, but with different branch: https://github.com/StackOverflowExcept1on/wasm-builder-regression/tree/wasm32v1-none

    git clone https://github.com/StackOverflowExcept1on/wasm-builder-regression.git --branch wasm32v1-none
cd wasm-builder-regression/wasm-project
./check.sh

  11. alexcrichton commented on Dec 16, 2024

    @alexcrichton
    alexcrichton
    on Dec 16, 2024
    Member

    Oh, that's still the same bug at llvm/llvm-project#109443, which still hasn't been fixed.

  12. StackOverflowExcept1on commented on Mar 5, 2025

    @StackOverflowExcept1on
    StackOverflowExcept1on
    on Mar 5, 2025
    ContributorAuthor

    @alexcrichton I can confirm that this problem is solved at least in nightly Rust

  13. StackOverflowExcept1on
    closed this as completedon Mar 5, 2025

  14. StackOverflowExcept1on commented on Mar 5, 2025

    @StackOverflowExcept1on
    StackOverflowExcept1on
    on Mar 5, 2025
    ContributorAuthor

    nightly-2025-02-18 fixed my problem! It's most likely related to #135763

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.O-wasmTarget: WASM (WebAssembly), http://webassembly.org/P-mediumMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-untriagedUntriaged performance or correctness regression.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions