In call_wasm_with_hw_bound_check/call_native_with_hw_bound_check,
ensure to set up the stack boundary (wasm_exec_env_set_thread_info)
before checking the overflow.
It seems that the problem was introduced by:
https://github.com/bytecodealliance/wasm-micro-runtime/pull/2940
- Synchronize the GC spec tests to the commit from December 9. 2024.
- Revise the error messages to be consistent with the spec test cases.
- bypass gc spec test on the nuttx platform as a workaround
While resolving linked globals in multi-module mode, WAMR tries to copy
the linked global's initial value into the destination global in the
current module. However, a bug in the implementation causes the copy to
be done from the InitializerExpression struct, not from its WASMValue
field.
This did not come up in WAMR's spec test runner because those are built
with WASM_ENABLE_SPEC_TEST, which means these globals are resolved as
builtins, not linked globals, which goes through a different (presumably
not faulty) path.
Add table64 extension(in Memory64 proposal) support in classic-interp
and AOT running modes, currently still use uint32 to represent table's
initial and maximum size to keep AOT ABI unchanged.
Add no_resolve to LoadArgs and wasm_runtime_resolve_symbols so one can
delay resolving of symbols.
This is useful for inspecting the module between loading and instantiating.
Now that WAMR supports multiple memory instances, this PR adds some APIs
to access them in a standard way.
This involves moving some existing utility functions out from the
`WASM_ENABLE_MULTI_MODULE` blocks they were nested in, but multi-memory
and multi-module seem independent as far as I can tell so I assume that's okay.
APIs added:
```C
wasm_runtime_lookup_memory
wasm_runtime_get_default_memory
wasm_runtime_get_memory
wasm_memory_get_cur_page_count
wasm_memory_get_max_page_count
wasm_memory_get_bytes_per_page
wasm_memory_get_shared
wasm_memory_get_base_address
wasm_memory_enlarge
```
Implement multi-memory for classic-interpreter. Support core spec (and bulk memory) opcodes now,
and will support atomic opcodes, and add multi-memory export APIs in the future.
PS: Multi-memory spec test patched a lot for linking test to adapt for multi-module implementation.
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.
- All files under *core/iwasm/libraries/wasi-nn* are compiled as shared libraries
- *wasi-nn.c* is shared between backends
- Every backend has a separated shared library
- If wasi-nn feature is enabled, iwasm will depend on shared library libiwasm.so
instead of linking static library libvmlib.a
Support to get `wasm_memory_type_t memory_type` from API
`wasm_runtime_get_import_type` and `wasm_runtime_get_export_type`,
and then get shared flag, initial page cout, maximum page count
from the memory_type:
```C
bool
wasm_memory_type_get_shared(const wasm_memory_type_t memory_type);
uint32_t
wasm_memory_type_get_init_page_count(const wasm_memory_type_t memory_type);
uint32_t
wasm_memory_type_get_max_page_count(const wasm_memory_type_t memory_type);
```
Support getting global type from `wasm_runtime_get_import_type` and
`wasm_runtime_get_export_type`, and add two APIs:
```C
wasm_valkind_t
wasm_global_type_get_valkind(const wasm_global_type_t global_type);
bool
wasm_global_type_get_mutable(const wasm_global_type_t global_type);
```
Fix aot debugger compilation error on windows as reported in #3184.
And update the stack size configuration for product-mini zephyr sample
since the native stack overflow check was enhanced and the zephyr-sdk
was also upgraded.
- Add a few API (https://github.com/bytecodealliance/wasm-micro-runtime/issues/3325)
```c
wasm_runtime_detect_native_stack_overflow_size
wasm_runtime_detect_native_stack_overflow
```
- Adapt the runtime to use them
- Adapt samples/native-stack-overflow to use them
- Add a few missing overflow checks in the interpreters
- Build and run the sample on the CI
Enhance the GC subtyping checks:
- Fix issues in the type equivalence check
- Enable the recursive type subtyping check
- Add a equivalence type flag in defined types of aot file, if there is an
equivalence type before, just set it true and re-use the previous type
- Normalize the defined types for interpreter and AOT
- Enable spec test case type-equivalence.wast and type-subtyping.wast,
and enable some commented cases
- Enable set WAMR_BUILD_SANITIZER from cmake variable
- Add new API wasm_runtime_load_ex() in wasm_export.h
and wasm_module_new_ex in wasm_c_api.h
- Put aot_create_perf_map() into a separated file aot_perf_map.c
- In perf.map, function names include user specified module name
- Enhance the script to help flamegraph generations
Fix the warnings and issues reported:
- in Windows platform
- by CodeQL static code analyzing
- by Coverity static code analyzing
And update CodeQL script to build exception handling and memory features.
Adding a new cmake flag (cache variable) `WAMR_BUILD_MEMORY64` to enable
the memory64 feature, it can only be enabled on the 64-bit platform/target and
can only use software boundary check. And when it is enabled, it can support both
i32 and i64 linear memory types. The main modifications are:
- wasm loader & mini-loader: loading and bytecode validating process
- wasm runtime: memory instantiating process
- classic-interpreter: wasm code executing process
- Support memory64 memory in related runtime APIs
- Modify main function type check when it's memory64 wasm file
- Modify `wasm_runtime_invoke_native` and `wasm_runtime_invoke_native_raw` to
handle registered native function pointer argument when memory64 is enabled
- memory64 classic-interpreter spec test in `test_wamr.sh` and in CI
Currently, it supports memory64 memory wasm file that uses core spec
(including bulk memory proposal) opcodes and threads opcodes.
ps.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/3091https://github.com/bytecodealliance/wasm-micro-runtime/pull/3240https://github.com/bytecodealliance/wasm-micro-runtime/pull/3260