Wamr Loader/GC giving a type mismatch failure

[nickbetteridge]

I'm too sure whether the issue I'm having is with the ocaml wasm compiler or with the bytecodealliance's runtime (wamr).

I've wrote a simple ocaml program:

let _ = Printf.printf "Hello")

compiled it with:

ocamlfind ocamlc -package js_of_ocaml -linkpkg -o hello.byte hello.ml

generated the wasm:

wasm_of_ocaml hello.byte

After building the wamr runtime with the following flags ...

-DWAMR_BUILD_TAIL_CALL=1
-DWAMR_BUILD_EXCE_HANDLING=1
-DWAMR_BUILD_GC=1

... I was able to run a simple wasm file generated from C.

When attempting to run the ocaml wasm file I got the following error:

WASM module load failed: type mismatch: expect (ref ht) but got other

So, could anyone suggest possible ways for me to narrow down the cause of the error?

[vouillon]

I think I fixed this issue in bytecodealliance/wasm-micro-runtime#4075.

But the implementation of the GC proposal in WAMR is partial and not sufficient to run programs produced by wasm_of_ocaml. I have just reopened an issue: bytecodealliance/wasm-micro-runtime#4190

[nickbetteridge]

Ah, sorry - you're right, I was using an older commit.

However, I rebuilt and this time got a unhandled SIGSEGV, si_addr: 0x575800000002 - it does seem to be fragile

What's the best way of debugging this? Perhaps I should just raise a new issue on bytecodealliance/wasm-micro-runtime?

[vouillon]

You can get a backtrace by running it with gdb:

gdb --args ~/sources/wasm-micro-runtime/product-mini/platforms/linux/build/iwasm hello.assets/code*.wasm

It seems it fails because the Wasm module is not a WASI module, and then crashes while trying to unload the module. You can raise an issue on bytecodealliance/wasm-micro-runtime, indeed. By the way, if you want to produce WASI modules (which do not depend on some JavaScript helper code), you should use #1831 and compile using the --enable wasi option.

0x000055555567bb68 in destroy_init_expr_data_recursive (module=0x55555574d340, 
    data=0x555500000005)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:509
509	    wasm_type = module->types[struct_init_values->type_idx];
(gdb) bt
#0  0x000055555567bb68 in destroy_init_expr_data_recursive (
    module=0x55555574d340, data=0x555500000005)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:509
#1  0x000055555567bd7a in destroy_init_expr_data_recursive (
    module=0x55555574d340, data=0x55555577f790)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:552
#2  0x000055555567bc72 in destroy_init_expr_data_recursive (
    module=0x55555574d340, data=0x55555577f970)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:535
#3  0x00005555556a5f7d in destroy_init_expr (module=<optimized out>, 
    expr=<optimized out>)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:647
#4  destroy_init_expr (module=<optimized out>, expr=<optimized out>)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:642
#5  wasm_loader_unload (module=0x55555574d340)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:6889
#6  0x00005555556a69ac in wasm_loader_load (buf=buf@entry=0x7ffff7e56010 "", 
    size=size@entry=167172, args=args@entry=0x7fffffffd580, 
    error_buf=error_buf@entry=0x7fffffffd8f0 "WASM module load failed: a module with WASI apis must export memory by default", 
    error_buf_size=error_buf_size@entry=128)
    at /home/jerome/sources/wasm-micro-runtime/core/iwasm/interpreter/wasm_loader.c:6794

[nickbetteridge]

Thanks for the above! Yes, after building the wasi branch, array as a field in struct object is definitely a show stopper - I'll add frustration to 4190. Thanks again for your help

[nickbetteridge]

I think I fixed this issue in bytecodealliance/wasm-micro-runtime#4075.

But the implementation of the GC proposal in WAMR is partial and not sufficient to run programs produced by wasm_of_ocaml. I have just reopened an issue: bytecodealliance/wasm-micro-runtime#4190

I'm going to spend some time on this soon - any suggestions on how to proceed? - ie do I need to attempt to implement the whole gc spec for ocaml on wamr or do I just need a subset?

[vouillon]

The GC spec is already mostly implemented. I think there are only two things missing, both related to the initialization of global variables.

First, WAMR does not support nesting arrays inside structures in constant expressions:

(type $bytes (array (mut i8)))
(type $struct (struct (field (ref $bytes))))
(global $s (ref $struct)
   (struct.new $struct (array.new_fixed $bytes 1 (i32.const 48))))

This should not be too hard to fix by refactoring a bit core/iwasm/interpreter/wasm_runtime.c.

The other issue is that, with the GC proposal, global.get is a constant instruction and can access preceding (immutable) global definitions:

(type $bytes (array (mut i8)))
(type $block (array (ref eq)))
(global $a (ref $bytes) (array.new_fixed $bytes 1 (i32.const 48)))
(global $b (ref $block) (array.new_fixed $block 1 (global.get $a)))

Given the way the initialization of global variables is performed in WAMR, that might be complicated to implement. But as a temporary workaround, I could add a flag to wasm_of_ocaml so that it does not generate this kind of code.

[nickbetteridge]

Thanks for the above! I'll get onto it as soon as I possibly can. Adding a flag to wasm_of_ocaml would be useful - certainly in the early stages of getting wamr/ocaml to work.