You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
WAMR's spec test runner checks to see that there is a linker failure in the STDOUT or STDERR of the iwasm repl, which there is. But this failure does not actually prevent module instantiation like the spec says it should.
I'm curious about WAMR's behavior in this scenario. It seems like a deliberate choice, but I'd like to understand why. Thanks!
The text was updated successfully, but these errors were encountered:
I think the choice of warning over error is that this import function may not be used. If it's actually used, it will report an exception error in runtime.
Hi all, I was just wondering why module imports are treated specially during module instantiation (compared to table, global and memories). If a linked global, table or memory cannot be found,
check_linked_symbol
will returnfalse
, e.g. see https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/core/iwasm/interpreter/wasm_runtime.c#L1914.On the other hand, a missing function will log a warning, but will not otherwise prevent module instantiation. Unless I'm misunderstanding, this seems to contradict Rule 3 in https://webassembly.github.io/spec/core/exec/modules.html#exec-instantiation.
I came across this while writing my own spec test runner. In
imports.wast
spec test, we haveWAMR's spec test runner checks to see that there is a linker failure in the STDOUT or STDERR of the iwasm repl, which there is. But this failure does not actually prevent module instantiation like the spec says it should.
I'm curious about WAMR's behavior in this scenario. It seems like a deliberate choice, but I'd like to understand why. Thanks!
The text was updated successfully, but these errors were encountered: