it seems meaningless and quite confusing to access a table with
two aliases ("lookup" and "backends") within a function.
no functional changes are intended.
> **Fix a release-blocking issue**
---
Like:
```
vmlib.lib(blocking_op.obj) : error LNK2019: unresolved external symbol
__imp_wasm_runtime_begin_blocking_op referenced in function
blocking_op_close
[D:\a\wasm-micro-runtime\wasm-micro-runtime\wamr-compiler\build\wamrc.vcxproj]
vmlib.lib(blocking_op.obj) : error LNK2019: unresolved external symbol
__imp_wasm_runtime_end_blocking_op referenced in function
blocking_op_close
[D:\a\wasm-micro-runtime\wasm-micro-runtime\wamr-compiler\build\wamrc.vcxproj]
```
Especially when GC is enabled, a valid item of `module->types` needs additional
checks before casting to WASMFuncType.
Also, avoid overflowing if reftype_map_count is 0.
Additionally, correctly set IN_OSS_FUZZ based on CFLAGS_ENV for sanitizer
configuration. Update ASan and UBSan messages for clarity in non-oss-fuzz
environments.
This partly reverts "Cmake improvements".
(https://github.com/bytecodealliance/wasm-micro-runtime/pull/4076)
Recently we changed the location to install public headers.
For example,
Old: include/wasm_export.h
New: include/iwasm/wasm_export.h
For cmake-based user applications using find_package(iwasm),
the cmake package, namely target_include_directories(INSTALL_INTERFACE),
is expected to add necessary compiler options like -isystem automatically.
(See samples/printversion for an example of such user applications.)
However, in reality, not every user application uses cmake.
This commit reverts the location to install public headers
for now, to avoid breakage for non-cmake user applications.
In case we want to re-apply the location change in future,
we should better communicate to the users. (eg. document
migration proceduces in release notes.)
Fixes: https://github.com/bytecodealliance/wasm-micro-runtime/issues/4290
References:
https://cmake.org/cmake/help/latest/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES.html
> Process completed with exit code 143.
It will attempt to run spec test scripts three times if they end with code 143.
It is a known issue with GitHub-hosted runners. Usually, increasing the swap
file can help avoid it. However, sometimes error 143 still occurs. To prevent
confusion, let's capture error 143 and allow the CI to pass.
CMake 4 no longer sets the CMAKE_OSX_SYSROOT variable by default, causing the
lldb build to fail after all GitHub-hosted runners have been upgraded to
CMake 4.
As a workaround, the variable is set using CMake command line options. There
is a PR to fix this issue in the llvm-project:
https://github.com/llvm/llvm-project/pull/138020. We might want to remove
this workaround after that PR has been merged.
Mostly because of some observations:
- There is no actual usage reported.
- Both ide-ext and ide-docker-image have not been maintained for quite a while.
- At the very least, there is no need to recompile it every time when there are no modifications.
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.
As far as I know, we don't implement the proposal at all.
```
spacetanuki% wasm2wat --enable-all data.28.wasm
(module
(memory (;0;) 1)
(data (;0;) (i32.const 42
i32.const 0
i32.sub) ""))
spacetanuki% toywasm --load data.28.wasm
spacetanuki% ~/git/wasm-micro-runtime/product-mini/platforms/darwin/b.classic/iwasm data.28.wasm
WASM module load failed: illegal opcode or constant expression required or type mismatch
spacetanuki%
```
data.28.wasm in the above example is a binary version of:
8d4f6aa2b0/test/core/data.wast (L184-L187)
* initialize WASI stdio handles to invalid for better error handling
* implement os_invalid_raw_handle function for consistent invalid handle representation
- it's unused
- valgrind is basically a linux-only software.
it isn't a good idea to make it a hard requirement.
if we want to use valgrind, it's better to introduce
a separate option to control it.
LLVM 16 and later expands cttz intrinsic to a table lookup,
which involves some relocations. (unless ZBB is available,
in which case the native instructions are preferred over
the table-based lowering.)
cf. https://reviews.llvm.org/D128911
the corresponding LLVM intrinsics' return types are same as
their first argument. eg. i64 for llvm.cttz.i64.
cf. https://llvm.org/docs/LangRef.html#llvm-cttz-intrinsic
this commit changes the return types of our versions of the
intrinsics to match llvm versions as our aot compiler,
specifically __call_llvm_intrinsic, assumes.
strictly speaking, this is a potential AOT ABI change.
however, I suppose it isn't a problem for many of 64-bit ABIs
out there, where (lower half of) a 64-bit register is used to
return a 32-bit value anyway. (for such ABIs, this commit
would fix the upper 32-bit value of the register.)
