Stream: git-wasmtime

Topic: wasmtime / PR #11389 Cranelift: Translate `ir::UserExtern...

Wasmtime GitHub notifications bot (Aug 06 2025 at 23:15):

fitzgen opened PR #11389 from fitzgen:inlining-fuzz-bug to bytecodealliance:main:

This was an entity that we forgot to translate from the callee into the caller. Note that we do not use the EntityMap offset approach for these entities because ir::Function hash-conses them.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Aug 06 2025 at 23:15):

fitzgen requested abrown for a review on PR #11389.

Wasmtime GitHub notifications bot (Aug 06 2025 at 23:15):

fitzgen requested wasmtime-compiler-reviewers for a review on PR #11389.

Wasmtime GitHub notifications bot (Aug 06 2025 at 23:15):

fitzgen requested alexcrichton for a review on PR #11389.

Wasmtime GitHub notifications bot (Aug 06 2025 at 23:15):

fitzgen requested wasmtime-core-reviewers for a review on PR #11389.

Wasmtime GitHub notifications bot (Aug 06 2025 at 23:54):

alexcrichton submitted PR review:

While I agree this is more correct than before, I think there's still an underlying bug that we're misinterpreting UserExternalNameRef across functions. This PR is copying those blindly across functions but the way we've organized things right now they only hold meaning within the function itself. That's because the Cranelift namespace of UserExternalNameRef of 0 means "my local module", so when a function is inlined then any calls in that function now mistakenly mean "calls to my own local module" when actually they should be into the module that was inlined-from.

An example test is:

(component
  (core module $A
    (func (export "f0") (result i32) (i32.const 0))
    (func (export "f1") (result i32) (call $not-inlined) (i32.const 1))
    (func $not-inlined )
  )

  (core module $B
    (import "a" "f0" (func $f0 (result i32)))
    (import "a" "f1" (func $f1 (result i32)))
    (func (export "f2") (result i32)
      (call $f1)
    )
  )

  (core module $C
    (import "b" "f2" (func $f2 (result i32)))
    (func (export "f3") (result i32)
      (call $f2)
    )
  )

  (core instance $a (instantiate $A))
  (core instance $b (instantiate $B (with "a" (instance $a))))
  (core instance $c (instantiate $C (with "b" (instance $b))))

  (func (export "f") (result u32)
    (canon lift (core func $c "f3"))
  )
)

which, with this PR, fails to compile with inlining with:

thread 'main' panicked at crates/wasmtime/src/compile.rs:906:43:
no entry found for key
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

So I think we're somehow going to need to either perform a "map" over UserExternalNameRef during inlining or refactor what we're telling Cranelift the names of these functions are

Wasmtime GitHub notifications bot (Aug 07 2025 at 00:41):

fitzgen commented on PR #11389:

Yes, I did not mean to imply this fixes all the fuzz bugs. Just one bug. More to come

Wasmtime GitHub notifications bot (Aug 07 2025 at 00:45):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Aug 07 2025 at 16:41):

fitzgen merged PR #11389.

Last updated: Dec 06 2025 at 06:05 UTC