JIT runtime failed to initiate panic

[dtolnay]

Panics seem to get printed decently by the interpreted runtime, but not the JIT runtime.

To reproduce, cherry-pick 149ca1a421e461ecb1f88cb1b37fcceb9dd6b653 and then:

$ cargo build --release --target wasm32-unknown-unknown --manifest-path demo/impl/Cargo.toml && cargo run --manifest-path demo/caller/Cargo.toml

error: proc-macro derive panicked
 --> demo/caller/src/main.rs:3:10
  |
3 | #[derive(Demo)]
  |          ^^^^
  |
  = help: message: panicked at 'oh no!', src/lib.rs:5:5

$ cargo build --release --target wasm32-unknown-unknown --manifest-path demo/impl/Cargo.toml && WATT_JIT=/git/wasmtime/target/release/libwasmtime_api.so cargo run --manifest-path demo/caller/Cargo.toml

fatal runtime error: failed to initiate panic, error 5
error: could not compile `watt-demo-caller`.

[dtolnay]

Is this because we are panicking across an FFI boundary?

[alexcrichton]

Ah yes this is a known issue with wasmtime. This is definitely related to the FFI boundary, but it's also related to JIT code generation in wasmtime.

I think the best strategy (for watt) is to ideally do something like:

• Catch wasm panics with a custom hook
• Tell the watt runtime what the panic message is
• Force a trap to happen in wasm (let the wasm panic continue)
• Catch the wasm trap in the caller
• Look to see if a panic message was registered, and if so raise that panic. Otherwise raise an "abnormal trap" error for the wasm

That should avoid crossing any boundaries or dealing with JIT code and should work everywhere so long as wasm traps work everywhere.

[dtolnay]

Sounds good!