* introduce wasm_runtime_instantiate_ex2
at this point, just a slightly inefficiant functionality
equivalent of wasm_runtime_instantiate_ex.
however, unlike wasm_runtime_instantiate_ex, this one is designed
to be extendable without breaking the user-visible ABI.
because the definition of InstantiationArgs2 is not exposed to
users, we can safely add new members to it.
this commit also makes wasm_runtime_instantiate_ex a wrapper
of wasm_runtime_instantiate_ex2.
if this goes well, maybe it's a good idea to apply a similar
pattern to RuntimeInitArgs, LoadArgs, SharedHeapInitArgs, etc.
i started with InstantiationArgs just because i happen to have
a need to extend it for wasi-nn.
cf.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/4364https://github.com/bytecodealliance/wasm-micro-runtime/issues/4331
* product-mini/platforms/posix: use wasm_runtime_instantiate_ex2
Propose two enhancements:
- Shared heap created from preallocated memory buffer: The user can create a shared heap from a pre-allocated buffer and see that memory region as one large chunk; there's no need to dynamically manage it(malloc/free). The user needs to make sure the native address and size of that memory region are valid.
- Introduce shared heap chain: The user can create a shared heap chain, from the wasm app point of view, it's still a continuous memory region in wasm app's point of view while in the native it can consist of multiple shared heaps (each of which is a continuous memory region). For example, one 500MB shared heap 1 and one 500 MB shared heap 2 form a chain, in Wasm's point of view, it's one 1GB shared heap.
After these enhancements, the data sharing between wasm apps, and between hosts can be more efficient and flexible. Admittedly shared heap management can be more complex for users, but it's similar to the zero-overhead principle. No overhead will be imposed for the users who don't use the shared heap enhancement or don't use the shared heap at all.
- Change `WAMR_ENABLE_COPY_CALLSTACK` to `WAMR_BUILD_COPY_CALL_STACK`, as
`WAMR_BUILD` is the prefix for a command line option.
- Change `WAMR_ENABLE_COPY_CALLSTACK` to `WASM_ENABLE_COPY_CALL_STACK`, as
`WASM_ENABLE` is the prefix for a macro in the source code.
- Change `CALLSTACK` to `CALL_STACK` to align with the existing
`DUMP_CALL_STACK` feature.
- Continue using `WASMCApiFrame` instead of `wasm_frame_t` outside of
*wasm_c_api.xxx* to avoid a typedef redefinition warning, which is
identified by Clang.
Previously, if the user sets their own stack boundary, we still compute
the thread stack boundary (which is expensive), then immediately discard
the result. This change makes the expensive call only if we need it for
sure.
- 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
Filesystem paths can be mapped from the host path to a guest path using
the format `<guest-path>::<host-path>`.
Previously `strtok` was used to find the `::` delimiter. Unfortunately
`strtok` processes each delimiter character individually. This meant
that the code was ~equivalent to `strtok(mapping_copy, ":")` which
breaks with Windows-style paths (E.g. `C:\my_path\`).
To fix this `strstr` is used to search for the exact delimiter.
When checking for integer overflow, you may often write tests like p + i < p.
This works fine if p and i are unsigned integers, since any overflow in the
addition will cause the value to simply "wrap around." However, using this
pattern when p is a pointer is problematic because pointer overflow has
undefined behavior according to the C and C++ standards. If the addition
overflows and has an undefined result, the comparison will likewise be
undefined; it may produce an unintended result, or may be deleted entirely
by an optimizing compiler.
- Clear some compile warnings
- Fix some typos
- Fix llvm LICENSE link error
- Remove unused aot file and binarydump bin
- Add checks when loading AOT exports
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.
