Compilation warnings were reported on mac:
```
core/shared/mem-alloc/ems/ems_gc.c:454:22: warning: passing arguments to 'wasm_runtime_gc_prepare' without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
gct_vm_gc_prepare(NULL);
^
core/shared/mem-alloc/ems/ems_gc.c:466:23: warning: passing arguments to 'wasm_runtime_gc_finalize' without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
gct_vm_gc_finished(NULL);
^
2 warnings generated.
```
As reported in #3500, when debug interpreter is enabled, the classic interpreter
performs a lock operation to read `exec_env->current_status->signal_flag` and
do further handling before fetching next opcode, which makes the interpreter
run slower.
This PR atomic loads the `exec_env->current_status->signal_flag` without mutex
lock when 32-bit atomic load is supported, and only adding lock for further
handling when the signal_flag is WAMR_SIG_SINGSTEP, which improves the
performance.
There's probably a number of other places where the bh_leb_read could be used (e.g. aot loader)
but I'm making the change as small as possible. Further refactoring can be done later.
Fix:
```
wamr/core/iwasm/libraries/libc-builtin/libc_builtin_wrapper.c:20:1:
warning: type of 'wasm_runtime_module_realloc' does not match original declaration [-Wlto-type-mismatch]
wamr/core/iwasm/common/wasm_runtime_common.c:3033:1:
note: return value type mismatch
wamr/core/iwasm/common/wasm_runtime_common.c:3033:1:
note: type 'uint64' should match type 'uint32'
wamr/core/iwasm/common/wasm_runtime_common.c:3033:1:
note: 'wasm_runtime_module_realloc' was previously declared here
wamr/core/iwasm/common/wasm_runtime_common.c:3033:1:
note: code may be misoptimized unless '-fno-strict-aliasing' is used
```
Some host environment may also create an signal alternate stack and access
it after the wasm runtime exits, the runtime should backup the stack info and
restore it before thread exits.
The issue was found in golang:
```
signal 23 received on thread with on signal stack
fatal error: non-Go code disabled signaltstack
```
Add support for the [Zephyr Usermode](https://docs.zephyrproject.org/latest/kernel/usermode/index.html)
to the Zephyr port.
The following changes are applied:
- Fix `signbit`, check if it is defined already and only implement it, if not
- Introduce `sys_mutex` and `sys_sem` in favour of `k_mutex` and `k_sem`, when `CONFIG_USERMODE` is enabled
- Remove the installation of the `_stdout_hook_iwasm()` when `CONFIG_USERMODE` is enabled, otherwise this
causes MPU errors since the std hook is in the kernel space
- Add a thread name for debugging
The "handlers" on the interpreter stack is sometimes treated as
host pointers and sometimes treated as i64 values. It's quite broken
for targets where pointers are not 64-bit.
This commit makes them host pointers consistently. (at least for
32-bit and 64-bit pointers. We don't support other pointer
sizes anyway.)
Fixes https://github.com/bytecodealliance/wasm-micro-runtime/issues/3110
Fix several issues of GC and exception handling in wasm loader:
- Should restore param_reftype_maps/param_reftype_map_count/param_count
in the handling of opcode throw
- Should set wasm_ref_type when pushing param types of tag type and block type
if the type is a multi-byte type
- Should set init_values.data as NULL for opcode struct.new_default in load_init_expr
This PR fixes the issues reported in #3411.
Check whether the indices overflow UINT32_MAX or not for:
- import function count + function count
- import global count + global count
- import tag count + tag count
This PR fixes the issue reported by Oss-fuzz test (#69920).
We need to fix numpy version since the latest is incompatible.
> A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.0.0 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.
- Split the `aot_loader_resolve_function` into two functions to prevent
redundant module lookups and loads
- Access pre-associated module instances from `import_func_module_insts`,
avoiding unnecessary instance lookups and improving performance
aot_load_const_from_table() hides the const-ness of the
value and prevents optimizations like
https://github.com/bytecodealliance/wasm-micro-runtime/pull/3552.
This commit makes the aot compiler tracks the const-ness
of the value directly in the AOTValue and enables the above
mentioned optimization for XIP.
* I believe that LLVM MemoryBuffer interface is supposed to be read-only
and it's allowed to use eg. read-only mmap of the underlying file.
It isn't appropriate to modify the view at all.
* in case of WASM_ENABLE_DEBUG_AOT, the whole buffer is written as the text
section of the aot file. the modified e_type would confuse dwarf consumers.
note that, even when we are using XIP, the debug info usually contains
relocations. for example, llvm-dwarfdump doesn't seem to perform relocations
on .debug_info section for ET_CORE (== 4 == our E_TYPE_XIP) objects.
The wasm loader is failing when multi-module support is on and the dependent
modules are not found; this enforces the AOT compiler integrations to prepare
dependent modules while it isn't necessary.
This PR allows allows missing imports in wasm loader and report error in wasm
instantiation instead, which enables the integrated AOT compiler to work as if
the multi-module support isn't turned on.
Fix#3545 and update the build configuration for multi-module sample:
- pass debug to AOT-compiled modules
- support optional DUMP_CALL_STACK
- support optional GC
