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.)
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)
for x86-64, llvm 17 and later sometimes uses "l" prefix
for data sections.
cf. 43249378da
because our aot file emitter/loader doesn't support such
sections, it ends up with load-time errors solving symbols like ".lrodata".
this commit fixes it by avoid placing data in the large data sections.
references:
https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU1feb00a28c
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. 41895843b5
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
There are two reasons for this optimization:
- The value of dlen can equal 0x1_0000_0000, even in wasm32 mode, because it is derived from (4G-0). This results in a truncation when it is passed to b_memmove_s(). Consequently, s1max becomes 0 and n is greater than s1max. To correct this, a longer type is required.
- The dlen is only used to check if there is enough space in b_memmove_s(). However, from a different angle, after confirming that both src+len and dst+len are within the memory range, we can be assured and there is no need for this explicit check.
* Fix errors on the "i386-windows-msvc" platform
* Refactor symbol name handling for AOT COFF32 binary format
* Fix preprocessor directive placement for Windows compatibility in aot_reloc_x86_32.c
---------
Co-authored-by: liang.he@intel.com <liang.he@intel.com>
```
CMake Error at CMakeLists.txt:4 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
```
In call_wasm_with_hw_bound_check/call_native_with_hw_bound_check,
ensure to set up the stack boundary (wasm_exec_env_set_thread_info)
before checking the overflow.
It seems that the problem was introduced by:
https://github.com/bytecodealliance/wasm-micro-runtime/pull/2940
