> 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:
https://github.com/WebAssembly/extended-const/blob/8d4f6aa2b00a8e7c0174410028625c6a176db8a1/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.)
Replace up_invalidate_dcache_all() with up_flush_dcache_all() in
os_dcache_flush() to properly flush the data cache instead of just
invalidating it. This ensures that any modified data in the cache
is written back to memory before execution.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
LLVM 19 and later started to use srodata ("small read only data")
sections for RISCV. cf. https://github.com/llvm/llvm-project/pull/82214
this commit makes our aot emitter/loader deal with those sections.
an alternative would be to disable small data sections completely by
setting the "SmallDataLimit" module attribute to zero. however, i feel
this commit is more straightforward and consisitent as we are already
dealing with sdata sections.
LLVM, by default, disables the use of C++'s built-in Run-Time Type Information.
This decision is primarily driven by concerns about code size and efficiency.
But '-fsanitize=vptr' not allowed with '-fno-rtti'.
while ideally a user should not need to care this kind of
optimization details, in reality i guess it's sometimes useful.
both of clang and GCC expose a similar option. (-fno-jump-tables)
LLVM 18 and later, instcombine perfoms only one iteration.
it performs extra "verify fixpoint" operation when instcombine
is specified in certain ways, including how we do so here.
a problem is that the verification raises a fatal error when it
finds we didn't reach a fixpoint:
LLVM ERROR: Instruction Combining did not reach a fixpoint
after 1 iterations
while it should be rare, it's quite normal not to reach a fixpoint.
this commit fixes the issue by simply disabing the verification.
cf. https://github.com/llvm/llvm-project/commit/41895843b5915bb78e9d02aa711fa10f7174db43
Raise wasi-sdk to 25 and wabt to 1.0.37. It includes
- Refactor CI workflow to install WASI-SDK and WABT from a composite action
- Use ExternalProject to bring wasm-apps for few samples. file/ wasi-threads/
- Refactor sample build and test steps in SGX compilation workflow for improved clarity and efficiency (workaround)
Add CMake support for EMSCRIPTEN and WAMRC, update module paths
