Stream: git-wasmtime

Topic: wasmtime / issue #12353 Pulley: ABI mismatch between comp...

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2026 at 00:32):

zzjas opened issue #12353:

While looking at Pulley, we found a potential ABI issues but it's not trivial to test with the exisitng testing infrastructure so I'm opening this issue to see if it should be fixed and/or tested. Happy to submit a PR! Thanks!

Mismatch between compiler and interpreter

Compiler doesn't use x15 for argument,
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/cranelift/codegen/src/isa/pulley_shared/abi.rs#L61-L70

the call_end in interpreter was updated to correctly follow this
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/pulley/src/interp.rs#L169-L178

but call_start is still using x15
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/pulley/src/interp.rs#L110-L114

Probably this is just a subtle oversight that is very easy to fix, but I'm not sure how to properly test it (or if it needs a test at all).

For now I have a lengthy Rust test that compiles a piece of clif code to Pulley, invokes VM::call, and check the result.

Another question about Pulley: we also noticed that the compute_arg_locs for Pulley will split a single i128 argument across a register and the stack when only one register is available. I didn't find any document about this so just want to ask if this is the intended behavior.

Thanks for looking into this!

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2026 at 00:32):

zzjas added the cranelift label to Issue #12353.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2026 at 00:32):

zzjas added the bug label to Issue #12353.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2026 at 00:33):

zzjas edited issue #12353:

While looking at Pulley, we found a potential ABI issue but it's not trivial to test with the exisitng testing infrastructure so I'm opening this issue to see if it should be fixed and/or tested. Happy to submit a PR! Thanks!

Mismatch between compiler and interpreter

Compiler doesn't use x15 for argument,
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/cranelift/codegen/src/isa/pulley_shared/abi.rs#L61-L70

the call_end in interpreter was updated to correctly follow this
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/pulley/src/interp.rs#L169-L178

but call_start is still using x15
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/pulley/src/interp.rs#L110-L114

Probably this is just a subtle oversight that is very easy to fix, but I'm not sure how to properly test it (or if it needs a test at all).

For now I have a lengthy Rust test that compiles a piece of clif code to Pulley, invokes VM::call, and check the result.

Another question about Pulley: we also noticed that the compute_arg_locs for Pulley will split a single i128 argument across a register and the stack when only one register is available. I didn't find any document about this so just want to ask if this is the intended behavior.

Thanks for looking into this!

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2026 at 00:33):

zzjas edited issue #12353:

While looking at Pulley, we found a potential ABI issue but it's not trivial to test with the exisitng testing infrastructure so I'm opening this issue to see if it should be fixed and/or tested. Happy to submit a PR! Thanks!

Mismatch between compiler and interpreter

Compiler doesn't use x15 for argument,
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/cranelift/codegen/src/isa/pulley_shared/abi.rs#L61-L70

the call_end in interpreter was updated to correctly follow this
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/pulley/src/interp.rs#L169-L178

but call_start is still using x15
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/pulley/src/interp.rs#L110-L114

Probably this is just a subtle oversight that is very easy to fix, but I'm not sure how to properly test it (or if it needs a test at all).

For now I have a lengthy Rust test that compiles a piece of clif code to Pulley, invokes VM::call, and check the result.

Another question about Pulley: we also noticed that the compute_arg_locs for Pulley will split a single i128 argument across a register and the stack when only one register is available. I didn't find any document about this so just want to ask if this is the intended behavior.

Thanks for looking into this!

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2026 at 04:34):

alexcrichton commented on issue #12353:

Ah yeah this is a mistake that's fine to fix. I don't believe this is surfaceable via wasm itself because call_{start,end} is only used with a single type signature (our entry trampoline) which doesn't have 16+ arguments. Regardless though still good to fix for future use of pulley!

For i128 I think we're probably inheriting whatever native platforms do in that regard, but tweaking that to fix any issues arising is also totally ok as it's not used in the call_{start,end} path either

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2026 at 17:37):

zzjas commented on issue #12353:

Ah yeah this is a mistake that's fine to fix.

Created a PR for the first fix.

For i128 I think we're probably inheriting whatever native platforms do in that regard, but tweaking that to fix any issues arising is also totally ok as it's not used in the call_{start,end} path either

I think right now there's no issue to fix since it's self consistent. From my brief checking, X64 and aarch64 doesn't split i128 but RISC-V splits so either way is fine as long as it's well defined & documented for Pulley (when args on stack is actually implemented for VM::call).

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2026 at 17:37):

zzjas edited a comment on issue #12353:

Thanks for looking into this!

Ah yeah this is a mistake that's fine to fix.

Created a PR for the first fix.

For i128 I think we're probably inheriting whatever native platforms do in that regard, but tweaking that to fix any issues arising is also totally ok as it's not used in the call_{start,end} path either

I think right now there's no issue to fix since it's self consistent. From my brief checking, X64 and aarch64 doesn't split i128 but RISC-V splits so either way is fine as long as it's well defined & documented for Pulley (when args on stack is actually implemented for VM::call).

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2026 at 22:06):

alexcrichton closed issue #12353:

While looking at Pulley, we found a potential ABI issue but it's not trivial to test with the exisitng testing infrastructure so I'm opening this issue to see if it should be fixed and/or tested. Happy to submit a PR! Thanks!

Mismatch between compiler and interpreter

Compiler doesn't use x15 for argument,
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/cranelift/codegen/src/isa/pulley_shared/abi.rs#L61-L70

the call_end in interpreter was updated to correctly follow this
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/pulley/src/interp.rs#L169-L178

but call_start is still using x15
https://github.com/bytecodealliance/wasmtime/blob/b856261dde3ea2624511fe4f48c3ed0790ddaa61/pulley/src/interp.rs#L110-L114

Probably this is just a subtle oversight that is very easy to fix, but I'm not sure how to properly test it (or if it needs a test at all).

For now I have a lengthy Rust test that compiles a piece of clif code to Pulley, invokes VM::call, and check the result.

Another question about Pulley: we also noticed that the compute_arg_locs for Pulley will split a single i128 argument across a register and the stack when only one register is available. I didn't find any document about this so just want to ask if this is the intended behavior.

Thanks for looking into this!

view this post on Zulip Wasmtime GitHub notifications bot (Jan 15 2026 at 22:26):

alexcrichton commented on issue #12353:

I suspect that's a result of Pulley starting out by copying much of the riscv64 code, so makes sense in that regard at least. It should be fine to tweak as necesary though if needed

Last updated: Jan 29 2026 at 13:25 UTC