Allow HW OOB exception propagate from callee to caller issue when multi-module is enabled

[TianlongLiang]

No description provided.

[TianlongLiang]

Will add a test case too

[lum1n0us]

There is another smaller solution by using wasm_exec_env_restore_module_inst() in call_wasm_with_hw_bound_check() when an exception occurs.

diff --git a/core/iwasm/interpreter/wasm_runtime.c b/core/iwasm/interpreter/wasm_runtime.c
index 7ac6a66f..81d1223a 100644
--- a/core/iwasm/interpreter/wasm_runtime.c
+++ b/core/iwasm/interpreter/wasm_runtime.c
@@ -3665,6 +3665,11 @@ call_wasm_with_hw_bound_check(WASMModuleInstance *module_inst,
         /* Restore operand frames */
         wasm_exec_env_set_cur_frame(exec_env, prev_frame);
         exec_env->wasm_stack.top = prev_top;
+        /* Restore instance*/
+        if ((uintptr_t)module_inst != (uintptr_t)exec_env->module_inst) {
+            wasm_exec_env_restore_module_inst(exec_env,
+                (WASMModuleInstanceCommon *)module_inst);
+        }
     }
 
     jmpbuf_node_pop = wasm_exec_env_pop_jmpbuf(exec_env);

[yamt]

i'm not sure why we need WASM_ENABLE_MULTI_MODULE handling in this low level logic.

exception propagation should be done regardless of hw bound check, shouldn't it?

[lum1n0us]

This specific case #4703 occurs only when an exception happens in the child module instance, and the main module instance fails to copy that exception, causing the problem.

We both agree that there is another simple solution for this issue.

However, in the short term, I can't determine under which circumstances it is necessary to switch module instances before calling a WASM function. Please enlighten me.

[yamt]

it's better to minimize the logic in signal handler.
can't you propagate the exception as wasm_exec_env_restore_module_inst does for some reasons? why not?

[lum1n0us]

Yes, that's one way to patch it.