- 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
* Update CMakeLists.txt of fuzzing
- enable software bound-check
- enable wasi
- disable libc builtin and multiple modules
* Fix off-by-one error in result offset calculation for function calls
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.
Previously, the loader would check the name of a new export against all
existing exports, leading to a quadratic running time.
This change makes the loader parse the entire export section. The
exports are then sorted by name, then adjacent exports are checked for
uniqueness.
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.
Currently, the open-source builds of wamrc set WASM_ENABLE_DUMP_CALL_STACK,
which causes these two fields to be emitted. They are required by aot_emit_exception.c.
Internally at Google, we don't enable call stack dumps, so we've been using the
attached patch to make sure the fields are emitted anyway.
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 TINY / STANDARD frame modes - tiny mode is only able to keep track on the IP
and func idx, STANDARD mode provides more capabilities (parameters, stack pointer etc.).
- Implement FRAME_PER_FUNCTION / FRAME_PER_CALL modes - frame per function adds
code at the beginning and at the end of each function for allocating / deallocating stack frame,
whereas in per-call mode the frame is allocated before each call. The exception is call to
the imported function, where frame-per-function mode also allocates the stack before the
`call` instruction (as it can't instrument the imported function).
At the moment TINY + FRAME_PER_FUNCTION is automatically enabled in case GC and perf
profiling are disabled and `values` call stack feature is not requested. In all the other cases
STANDARD + FRAME_PER_CALL is used.
STANDARD + FRAME_PER_FUNCTION and TINY + FRAME_PER_CALL are currently not
implemented but possible, and might be enabled in the future.
ps. https://github.com/bytecodealliance/wasm-micro-runtime/issues/3758
In the AOT compiler, allow the user to control stack boundary check when the boundary
check is enabled (e.g. `wamrc --bounds-checks=1`). Now the code logic is:
1. When `--stack-bounds-checks` is not set, it will be the same value as `--bounds-checks`.
2. When `--stack-bounds-checks` is set, it will be the option value no matter what the
status of `--bounds-checks` is.
