How to handle `ref.null 0`?

[lum1n0us]

ref.null 0 is valid under the GC specification but invalid under the current specification(only allow externref and funcref). This means a Wasm runtime should report a validation error when loading a Wasm module that contains ref.null 0 if GC is not enabled. The same applies to wamrc.

But the latest version of wamrc will not report a validation error. This is because:

• By design, unlike iwasm, wamrc is a full-feature component that uses execution switchers (command line options) instead of compilation flags to configure all supported features. So GC is always-on in wamrc.
• wamrc will validate the ref.null opcode in WebAssembly modules under the GC specification by always enabling the compilation flag WASM_ENABLE_GC. Although there is a --enable-gc option in wamrc's command line options which is able to disable gc during execution, this option is not passed to the WebAssembly loader and is only used during and after AOT loading.
• There should be an additional opcode validator in code generation (compilation) after WebAssembly loading in wamrc. However, in a specific case(WAMR JIT mode incorrectly outputs type_mismatch #4480), br 0 will skip all following opcodes, including ref.null 0.

In my opinion, there are still three options available to handle this ref.null 0.
a. pass command line options of wamrc to wasm loader. like an extra parameter in wasm_runtime_load().
b. add opcode validation in aot_validate_wasm()
c. in CMakeLists.txt of wamrc, make WASM_ENABLE_GC configurable.

From my perspective, options a. and b. are too burdensome since ref.null is the only opcode that currently requires extra attention. I prefer to use option c.

[yamt]

ref.null 0 is valid under the GC specification but invalid under the current specification(only allow externref and funcref). This means a Wasm runtime should report a validation error when loading a Wasm module that contains ref.null 0 if GC is not enabled. The same applies to wamrc.

But the latest version of wamrc will not report a validation error. This is because:

* By design, unlike iwasm, wamrc is a full-feature component that uses execution switchers (command line options) instead of compilation flags to configure all supported features. So GC is always-on in wamrc.

* wamrc will validate the `ref.null` opcode in WebAssembly modules under the GC specification by always enabling the compilation flag `WASM_ENABLE_GC`. Although there is a `--enable-gc` option in wamrc's command line options which is able to disable gc during execution, this option is not passed to the WebAssembly loader and is only used during and after AOT loading.

* There should be an additional opcode validator in code generation (compilation) after WebAssembly loading in wamrc. However, in a specific case([WAMR JIT mode incorrectly outputs type_mismatch #4480](https://github.com/bytecodealliance/wasm-micro-runtime/issues/4480)), `br 0` will skip all following opcodes, including `ref.null 0`.

In my opinion, there are still three options available to handle this ref.null 0. a. pass command line options of wamrc to wasm loader. like an extra parameter in wasm_runtime_load(). b. add opcode validation in aot_validate_wasm() c. in CMakeLists.txt of wamrc, make WASM_ENABLE_GC configurable.

From my perspective, options a. and b. are too burdensome since ref.null is the only opcode that currently requires extra attention. I prefer to use option c.

what's wrong with following the current practice?
ie.
set module->is_gc_used in the loader when it found the opcode in question.
make the aot compiler fail when !option->enable_gc && module->is_gc_used.

[kylo5aby]

ref.null 0 is valid under the GC specification but invalid under the current specification(only allow externref and funcref). This means a Wasm runtime should report a validation error when loading a Wasm module that contains ref.null 0 if GC is not enabled. The same applies to wamrc.
But the latest version of wamrc will not report a validation error. This is because:

* By design, unlike iwasm, wamrc is a full-feature component that uses execution switchers (command line options) instead of compilation flags to configure all supported features. So GC is always-on in wamrc.

* wamrc will validate the `ref.null` opcode in WebAssembly modules under the GC specification by always enabling the compilation flag `WASM_ENABLE_GC`. Although there is a `--enable-gc` option in wamrc's command line options which is able to disable gc during execution, this option is not passed to the WebAssembly loader and is only used during and after AOT loading.

* There should be an additional opcode validator in code generation (compilation) after WebAssembly loading in wamrc. However, in a specific case([WAMR JIT mode incorrectly outputs type_mismatch #4480](https://github.com/bytecodealliance/wasm-micro-runtime/issues/4480)), `br 0` will skip all following opcodes, including `ref.null 0`.

In my opinion, there are still three options available to handle this ref.null 0. a. pass command line options of wamrc to wasm loader. like an extra parameter in wasm_runtime_load(). b. add opcode validation in aot_validate_wasm() c. in CMakeLists.txt of wamrc, make WASM_ENABLE_GC configurable.
From my perspective, options a. and b. are too burdensome since ref.null is the only opcode that currently requires extra attention. I prefer to use option c.

what's wrong with following the current practice? ie. set module->is_gc_used in the loader when it found the opcode in question. make the aot compiler fail when !option->enable_gc && module->is_gc_used.

imho, I think it's similar to option b, we should know which opcodes should trigger module->is_gc_used

[lum1n0us]

The issue is that wasm_loader in wamrc will always follow the GC specification to parse ref.null 0 even when !option->enable_gc.

[yamt]

ref.null 0 is valid under the GC specification but invalid under the current specification(only allow externref and funcref). This means a Wasm runtime should report a validation error when loading a Wasm module that contains ref.null 0 if GC is not enabled. The same applies to wamrc.
But the latest version of wamrc will not report a validation error. This is because:

* By design, unlike iwasm, wamrc is a full-feature component that uses execution switchers (command line options) instead of compilation flags to configure all supported features. So GC is always-on in wamrc.

* wamrc will validate the `ref.null` opcode in WebAssembly modules under the GC specification by always enabling the compilation flag `WASM_ENABLE_GC`. Although there is a `--enable-gc` option in wamrc's command line options which is able to disable gc during execution, this option is not passed to the WebAssembly loader and is only used during and after AOT loading.

* There should be an additional opcode validator in code generation (compilation) after WebAssembly loading in wamrc. However, in a specific case([WAMR JIT mode incorrectly outputs type_mismatch #4480](https://github.com/bytecodealliance/wasm-micro-runtime/issues/4480)), `br 0` will skip all following opcodes, including `ref.null 0`.

In my opinion, there are still three options available to handle this ref.null 0. a. pass command line options of wamrc to wasm loader. like an extra parameter in wasm_runtime_load(). b. add opcode validation in aot_validate_wasm() c. in CMakeLists.txt of wamrc, make WASM_ENABLE_GC configurable.
From my perspective, options a. and b. are too burdensome since ref.null is the only opcode that currently requires extra attention. I prefer to use option c.

what's wrong with following the current practice? ie. set module->is_gc_used in the loader when it found the opcode in question. make the aot compiler fail when !option->enable_gc && module->is_gc_used.

imho, I think it's similar to option b, we should know which opcodes should trigger module->is_gc_used

isn't it a matter of setting it in one of case WASM_OP_REF_NULL in the loader?

[lum1n0us]

Honestly, I'm not sure which approach is correct or more feasible. #4547 is based on the workload. It will be costly to pass either enable_gc or the whole options to wasm_loader, and several following questions arise, like

• Does iwasm also need a --enable-gc option?
• Should iwasm use other options?
• Does iwasm need to add a full-feature mode similar to wamrc?