C-API: wasm_valtype_new_funcref panics

[amusingimpala75]

Expected behaviour:

wasm_valtype_new_funcref() or wasm_valtype_new(WASM_FUNCREF) return a wasm_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]

There is no wasm_valtype_new_funcref function in wasmtime. As for WASM_FUNCREF it exists and should be handled at

wasmtime/crates/c-api/src/types/val.rs

Line 38 in 3fa545b

WASM_FUNCREF => ValType::FuncRef,

. Are you using the latest wasmtime version?

[amusingimpala75]

wasmtime-v1.0.1-aarch64-macos-c-api

[amusingimpala75]

also include/wasm.h defines an inline wasm_valtype_new_funcref() which just defers to wasm_valtype_new(WASM_FUNCREF).

[amusingimpala75]

externref does not work either.

[alexcrichton]

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 the match 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]

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]

Could this be rust-lang/rust#97463?

[amusingimpala75]

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]

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]

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.

[amusingimpala75]

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]

Nevermind, I just have to use the debug build, not the release build.