Stream: git-wasmtime

Topic: wasmtime / issue #4993 C-API: wasm_valtype_new_funcref pa...

Wasmtime GitHub notifications bot (Oct 01 2022 at 23:17):

amusingimpala75 opened issue #4993:

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

Wasmtime GitHub notifications bot (Oct 01 2022 at 23:22):

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?

Wasmtime GitHub notifications bot (Oct 01 2022 at 23:29):

amusingimpala75 commented on issue #4993:

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

Wasmtime GitHub notifications bot (Oct 01 2022 at 23:30):

amusingimpala75 commented on issue #4993:

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

Wasmtime GitHub notifications bot (Oct 02 2022 at 23:03):

amusingimpala75 commented on issue #4993:

externref does not work either.

Wasmtime GitHub notifications bot (Oct 03 2022 at 15:28):

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 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.

Wasmtime GitHub notifications bot (Oct 03 2022 at 15:28):

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.

Wasmtime GitHub notifications bot (Oct 03 2022 at 17:39):

bjorn3 commented on issue #4993:

Could this be https://github.com/rust-lang/rust/issues/97463?

Wasmtime GitHub notifications bot (Oct 03 2022 at 22:38):

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.

Wasmtime GitHub notifications bot (Oct 04 2022 at 15:32):

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.

Wasmtime GitHub notifications bot (Oct 04 2022 at 15:34):

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.

Wasmtime GitHub notifications bot (Oct 04 2022 at 15:34):

alexcrichton closed issue #4993:

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

Wasmtime GitHub notifications bot (Oct 05 2022 at 00:42):

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.

Wasmtime GitHub notifications bot (Oct 05 2022 at 00:59):

amusingimpala75 commented on issue #4993:

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

Last updated: Nov 22 2024 at 17:03 UTC