wasm-split fuzz bug

[tlively]

bin/wasm-split -all test.wast --split --split-funcs=1 --export-prefix=__fuzz_split_ -o1 /dev/null -o2 /dev/null

(module
 (type $0 (func))
 (rec
  (type $1 (sub (func (param (ref null $3) (ref eq) i32 f64 v128) (result (ref extern)))))
  (type $2 (array (ref null $1)))
  (type $3 (sub (struct (field (mut i16)) (field (mut f64)))))
  (type $4 (func (result f32)))
  (type $5 (sub (func (result i32))))
  (type $6 (sub $1 (func (param structref eqref i32 f64 v128) (result (ref extern)))))
 )
 (rec
  (type $7 (sub (func (result i64))))
  (type $8 (sub (array f64)))
  (type $9 (sub final $3 (struct (field (mut i16)) (field (mut f64)) (field (mut i64)))))
  (type $10 (sub final $5 (func (result i32))))
  (type $11 (array (mut v128)))
 )
 (global $global$0 (mut (ref $7)) (ref.func $1))
 (export "global$_4" (global $global$0))
 (@binaryen.js.called)
 (func $0
 )
 (func $1 (type $7) (result i64)
  (unreachable)
 )
)

@aheejin

[tlively]

Found another one:

(module
 (type $none (func))
 ;; A table that is initially only used by a function we will move
 (table $tab 1 funcref)
 (func $f (type $none))
 (func $use_table (type $none)
  (call_indirect $tab (type $none) (i32.const 0))
 )
 ;; A global that refers to $f.
 ;; Crucially, wasm-split skips globals in its first indirection pass.
 (global $g (mut funcref) (ref.func $f))
 (export "g" (global $g))
 (export "use_table" (func $use_table))
)

bin/wasm-split -all test.wast --split --split-funcs=f,use_table -o1 p.wasm -o2 s.wasm

This moves $f to the second module, but leaves a direct call to it in the $trampoline_f function added to the primary module, causing an assertion failure in the binary writer.

Explanation from Gemini:

1. Function Moving: $f and $use_table are moved to s.wasm.
2. Sharing Phase: wasm-split analyzes p.wasm. It sees that $tab is no longer used in the primary module (since the only caller was moved) and is used in the secondary module. It moves the table from p.wasm to
   s.wasm.
3. Trampoline Creation: During the same sharing phase, it sees that global $g in p.wasm still refers to the moved function $f. It creates a trampoline in p.wasm to call $f.
4. Indirection: The trampoline needs to call $f indirectly. Since the original table was already moved to the secondary module, wasm-split creates a new, second table in p.wasm to hold the slot for $f.
5. Patching Failure: The secondary module contains logic to patch the table entries for $f. However, it patches the original moved table it now owns, while the primary module's trampoline is calling through
   the newly created table.
6. Execution Mismatch: When you call into the primary module's table, it hits an uninitialized entry (or a placeholder that throws an exception), even though the secondary module "successfully" patched what it
   thought was the correct table.

Gemini fixed this by adding additional calls to indirectCallsToSecondaryFunctions and setupTablePatching at the end of the pipeline, but I doubt this is the best solution.