amusingimpala75 opened issue #4993:
Expected behaviour:
wasm_valtype_new_funcref()
orwasm_valtype_new(WASM_FUNCREF)
return awasm_valtype_t *
with a FuncRef type.Actual behaviour:
errors with
thread '< unnamed>' panicked at 'unexpected kind: 129', crates/c-api/src/types/val.rs:40:14
and terminates
bjorn3 commented on issue #4993:
There is no wasm_valtype_new_funcref function in wasmtime. As for WASM_FUNCREF it exists and should be handled at https://github.com/bytecodealliance/wasmtime/blob/3fa545bd89d6e18e6e85eab57499ee9c9f5032f2/crates/c-api/src/types/val.rs?q=WASM_FUNCREF#L38. Are you using the latest wasmtime version?
amusingimpala75 commented on issue #4993:
wasmtime-v1.0.1-aarch64-macos-c-api
amusingimpala75 commented on issue #4993:
also include/wasm.h defines an inline
wasm_valtype_new_funcref()
which just defers towasm_valtype_new(WASM_FUNCREF)
.
amusingimpala75 commented on issue #4993:
externref does not work either.
alexcrichton commented on issue #4993:
Thanks for the report, but this looks like something may be going wrong on your end somewhere, although I'm not sure where. The error message
thread '< unnamed>' panicked at 'unexpected kind: 129', crates/c-api/src/types/val.rs:40:14
says that 129 wasn't expected but that's the value of
WASM_FUNCREF
which is in thematch
arm. This may mean that while you think you're using 1.0.1 you're using an older binary by accident or something like that (or a completely different binary?)I've tested this locally with the Python bindings for the C API and these functions work and return the expected result.
alexcrichton commented on issue #4993:
Although now that I think this could also be an aarch64-macos ABI-specific issue, unfortunately though I do not have access to such hardware to test myself.
bjorn3 commented on issue #4993:
Could this be https://github.com/rust-lang/rust/issues/97463?
amusingimpala75 commented on issue #4993:
I have not used Wasmtime previously, so it is not a stale binary problem.
Yeah, it just doesn’t make sense because WASM_FUNCREF is clearly being evaluated as 129 from vals.rs, but then a direct comparison to that variable in the rust function fails, so I suspect it might be the ABI problem.
alexcrichton commented on issue #4993:
Ok this is definitely an ABI issue. On an aarch64 linux system which I presume is similar enough ABI-wise to macos:
#include <stdint.h> extern void the_imported_func(uint8_t a); void foo() { the_imported_func(129); }
yields:
$ cc -c foo.c -I ./wasm-c-api/include -O && objdump -S foo.o foo.o: file format elf64-littleaarch64 Disassembly of section .text: 0000000000000000 <foo>: 0: a9bf7bfd stp x29, x30, [sp, #-16]! 4: 910003fd mov x29, sp 8: 12800fc0 mov w0, #0xffffff81 // #-127 c: 94000000 bl 0 <the_imported_func> 10: a8c17bfd ldp x29, x30, [sp], #16 14: d65f03c0 ret
where at
8
the operand is being sign extended from 8 to 32-bits.On Rust stable:
#[no_mangle] pub extern "C" fn wat(a: u8) -> bool { a == 129 }
yields:
$ rustc foo.rs -O --crate-type cdylib --emit obj && objdump -S foo.o foo.o: file format elf64-littleaarch64 Disassembly of section .text.wat: 0000000000000000 <wat>: 0: 7102041f cmp w0, #0x81 4: 1a9f17e0 cset w0, eq // eq = none 8: d65f03c0 ret
where the comparison is a 32-bit comparison hence the failure.
On nightly Rust, however:
$ rustc +nightly foo.rs -O --crate-type cdylib --emit obj && objdump -S foo.o foo.o: file format elf64-littleaarch64 Disassembly of section .text.wat: 0000000000000000 <wat>: 0: 12001c08 and w8, w0, #0xff 4: 7102051f cmp w8, #0x81 8: 1a9f17e0 cset w0, eq // eq = none c: d65f03c0 ret
Here the
and
fixes the issue.So @amusingimpala75 I think you'll need to compile with nightly Rust for now instead of using the precompiled artifacts for AArch64 macos for the time being.
alexcrichton commented on issue #4993:
Given that this is a rustc bug and otherwise
wasm.h
isn't something we can modify, I'm going to close this. This can be worked around with nightly Rust-compiled artifacts and looks like it will get fixed with time as that makes its way to stable.
alexcrichton closed issue #4993:
Expected behaviour:
wasm_valtype_new_funcref()
orwasm_valtype_new(WASM_FUNCREF)
return awasm_valtype_t *
with a FuncRef type.Actual behaviour:
errors with
thread '< unnamed>' panicked at 'unexpected kind: 129', crates/c-api/src/types/val.rs:40:14
and terminates
amusingimpala75 commented on issue #4993:
I have now tried building the c-api with +nightly (1.66.0-nightly, from Oct 3), and it is producing a binary with a different hash, but it still will not work, creating the same error. I've never really fiddled with Rust before, so maybe I just do not know what I am doing.
amusingimpala75 commented on issue #4993:
Nevermind, I just have to use the debug build, not the release build.
Last updated: Dec 23 2024 at 12:05 UTC