- 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
By default, the project() CMake command defaults to C and C++. [1]
Therefore, CMake might perform tests for both C and C++ compilers as
part of the configuration phase.
However, this has the consequence of the configuration phase to fail if
the system does not have a C++ toolchain installed, even if C++ is not
really used by the top-level project under the default settings.
Some configurations might still require a C++ toolchain, so
enable_language is selectively called under such circumstances.
[1]: https://cmake.org/cmake/help/latest/command/project.html
Since the top-level CMakelists.txt is appending `-fvisibility=hidden` to
the compile options, no public symbols are exported by default. This
forbids users from linking against the shared library.
Using `gcc/clang` attributes [1], it is possible to override the definition
for `WASM_RUNTIME_API_EXTERN` so that only required symbols are
correctly exported.
[1]: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
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.
`module_inst->table_count = module->import_table_count + module->table_count`,
using it as an index will go through `module->import_tables` and `module->tables`,
but aot init data is only available for non-import tables.
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.
