Fix aot debugger compilation error on windows as reported in #3184.
And update the stack size configuration for product-mini zephyr sample
since the native stack overflow check was enhanced and the zephyr-sdk
was also upgraded.
- Add a few API (https://github.com/bytecodealliance/wasm-micro-runtime/issues/3325)
```c
wasm_runtime_detect_native_stack_overflow_size
wasm_runtime_detect_native_stack_overflow
```
- Adapt the runtime to use them
- Adapt samples/native-stack-overflow to use them
- Add a few missing overflow checks in the interpreters
- Build and run the sample on the CI
Fix the integer overflow issue when checking target branch depth in opcode
br_table, and fix is_32bit_type not check VALUE_TYPE_ANY issue, which may
cause wasm_loader_push_frame_offset push extra unneeded offset.
Fix wasm loader integrity checks for opcode ref.func and opcode else:
for opcode ref.func, the function must be an import, exported, or present in a
table elem segment or global initializer to be used as the operand to ref.func,
for opcode else, there must not be an else opcode previously.
Reported in #3336 and #3337.
And fix mini loader PUSH_MEM_OFFSET/POP_MEM_OFFSET macro
definitions due to the introducing of memory64 feature.
Some issues are related with memory fragmentation, which may cause
the linear memory cannot be allocated. In WAMR, the memory managed
by the system is often trivial, but linear memory usually directly allocates
a large block and often remains unchanged for a long time. Their sensitivity
and contribution to fragmentation are different, which is suitable for
different allocation strategies. If we can control the linear memory's allocation,
do not make it from system heap, the overhead of heap management might
be avoided.
Add `mem_alloc_usage_t usage` as the first argument for user defined
malloc/realloc/free functions when `WAMR_BUILD_ALLOC_WITH_USAGE` cmake
variable is set as 1, and make passing `Alloc_For_LinearMemory` to the
argument when allocating the linear memory.
Enhance the GC subtyping checks:
- Fix issues in the type equivalence check
- Enable the recursive type subtyping check
- Add a equivalence type flag in defined types of aot file, if there is an
equivalence type before, just set it true and re-use the previous type
- Normalize the defined types for interpreter and AOT
- Enable spec test case type-equivalence.wast and type-subtyping.wast,
and enable some commented cases
- Enable set WAMR_BUILD_SANITIZER from cmake variable
The current frame was freed before tail calling to an import or native function
and the prev_frame was set as exec_env's cur_frame, so after the tail calling,
we should recover context from prev_frame but not current frame.
Found in https://github.com/bytecodealliance/wasm-micro-runtime/issues/3279.
When thread manager is enabled, the aux stack of exec_env may be allocated
by wasm_cluster_allocate_aux_stack or disabled by setting aux_stack_bottom
as UINTPTR_MAX directly. For the latter, no need to free it.
And fix an issue when paring `--gc-heap-size=n` argument for iwasm, and
fix a variable shadowed warning in fast-jit.
- Add new API wasm_runtime_load_ex() in wasm_export.h
and wasm_module_new_ex in wasm_c_api.h
- Put aot_create_perf_map() into a separated file aot_perf_map.c
- In perf.map, function names include user specified module name
- Enhance the script to help flamegraph generations
Fix the warnings and issues reported:
- in Windows platform
- by CodeQL static code analyzing
- by Coverity static code analyzing
And update CodeQL script to build exception handling and memory features.
This reverts commit 0e8d949440.
Because it doesn't make much sense anymore after we disabled debug info
processing on C++ functions in:
"aot debug: process lldb_function_to_function_dbi only for C".
Adding a new cmake flag (cache variable) `WAMR_BUILD_MEMORY64` to enable
the memory64 feature, it can only be enabled on the 64-bit platform/target and
can only use software boundary check. And when it is enabled, it can support both
i32 and i64 linear memory types. The main modifications are:
- wasm loader & mini-loader: loading and bytecode validating process
- wasm runtime: memory instantiating process
- classic-interpreter: wasm code executing process
- Support memory64 memory in related runtime APIs
- Modify main function type check when it's memory64 wasm file
- Modify `wasm_runtime_invoke_native` and `wasm_runtime_invoke_native_raw` to
handle registered native function pointer argument when memory64 is enabled
- memory64 classic-interpreter spec test in `test_wamr.sh` and in CI
Currently, it supports memory64 memory wasm file that uses core spec
(including bulk memory proposal) opcodes and threads opcodes.
ps.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/3091https://github.com/bytecodealliance/wasm-micro-runtime/pull/3240https://github.com/bytecodealliance/wasm-micro-runtime/pull/3260
The PR #3259 reverted PR #3192, it fixes#3210 but makes #3170 failed again.
The workaround is that we should update `ctx->dynamic_offset` only for opcode br
and should not update it for opcode br_if. This PR fixes both issue #3170 and #3210.
Some environment may call wasm_runtime_full_init/wasm_runtime_init multiple
times without knowing that runtime is initialized or not, it is better to add lock
and increase reference count during initialization.
ps. https://github.com/bytecodealliance/wasm-micro-runtime/discussions/3253.
Add cmake variable `-DWAMR_BUILD_AOT_INTRINSICS=1/0` to enable/disable
the aot intrinsic functions, which are normally used by AOT XIP feature, and
can be disabled to reduce the aot runtime binary size.
And refactor the code in aot_intrinsics.h/.c.
Should not update `ctx->dynamic_offset` in emit_br_info, since the `Part e` only
sets the dst offsets, the operand stack should not be changed, e.g., the stack
operands are to be used by the opcodes followed by `br_if` opcode.
Reported in https://github.com/bytecodealliance/wasm-micro-runtime/issues/3210.
The symbols in windows 32-bit may start with '_' and can not be found
when resolving the relocations to them. This PR ignores the underscore
when handling the relocation name of AOT_FUNC_INTERNAL_PREFIX, and
redirect the relocation with name "_aot_stack_sizes" to the relocation with
name ".aot_stack_sizes" (the name of the data section created).
ps.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/3216
- Merge unused field `used_to_be_wasi_ctx` in `AOTModuleInstance` into `reserved` area
- Add field `memory_lock` in `WASMMemoryInstance` for future refactor
- Go binding: fix type error
https://github.com/bytecodealliance/wasm-micro-runtime/issues/3220
- Python binding:
type annotation uses the union operator "|", which requires Python version >=3.10
This allows to know the beginning of the wasm address space. At the moment
to achieve that, we need to apply a `hack wasm_runtime_addr_app_to_native(X)-X`
to get the beginning of WASM memory in the nativ code, but I don't see a good
reason why not to allow zero address as a parameter value for this function.
This PR adds a max_memory_pages parameter to module instantiation APIs,
to allow overriding the max memory defined in the WASM module.
Sticking to the max memory defined in the module is quite limiting when
using shared memory in production. If targeted devices have different
memory constraints, many wasm files have to be generated with different
max memory values. And device constraints may not be known in advance.
Being able to set the max memory value during module instantiation allows
to reuse the same wasm module, e.g. by retrying instantiation with different
max memory value.
If the language is not specified, CMake will try to find C++ compiler, even
though it is not really needed in that case (as the project is only written in C).
The stack profiler `aot_func#xxx` calls the wrapped function of `aot_func_internal#xxx`
by using symbol reference, but in some platform like xtensa, it’s translated into a native
long call, which needs to resolve the indirect address by relocation and breaks the XIP
feature which requires the eliminating of relocation.
The solution is to change the symbol reference into an indirect call through the lookup
table, the code will be like this:
```llvm
call_wrapped_func: ; preds = %stack_bound_check_block
%func_addr1 = getelementptr inbounds ptr, ptr %func_ptrs_ptr, i32 75
%func_tmp2 = load ptr, ptr %func_addr1, align 4
tail call void %func_tmp2(ptr %exec_env)
ret void
```
Fix the errors reported in the sanitizer test of nightly run CI.
When the stack is in polymorphic state, the stack operands may be changed
after pop and push operations (e.g. stack is empty but pop op can succeed
in polymorphic, and the push op can push a new operand to stack), this may
impact the following checks to other target blocks of the br_table opcode.
This PR encompasses two complementing purposes:
A documentation on verifying an Intel SGX evidence as produced by WAMR,
including a guide for verification without an Intel SGX-enabled platform.
This also contains a small addition to the RA sample to extract specific
information, such as whether the enclave is running in debug mode.
A C# sample to verify evidence on trusted premises (and without Intel SGX).
Evidence is generated on untrusted environments, using Intel SGX.
The wasm_interp_call_func_bytecode is called for the first time with the empty
module/exec_env to generate a global_handle_table. Before that happens though,
the function checks if the module instance has bounds check enabled. Because
the module instance is null, the program crashes. This PR added an extra check to
prevent the crashes.
Implement the GC (Garbage Collection) feature for interpreter mode,
AOT mode and LLVM-JIT mode, and support most features of the latest
spec proposal, and also enable the stringref feature.
Use `cmake -DWAMR_BUILD_GC=1/0` to enable/disable the feature,
and `wamrc --enable-gc` to generate the AOT file with GC supported.
And update the AOT file version from 2 to 3 since there are many AOT
ABI breaks, including the changes of AOT file format, the changes of
AOT module/memory instance layouts, the AOT runtime APIs for the
AOT code to invoke and so on.
This increases the chance to use "short" calls.
Assumptions:
- LLVM preserves the order of functions in a module
- The wrapper function are smaller than the wrapped functions
- The target CPU has "short" PC-relative variation of call/jmp instructions
and they are preferrable over the "long" ones.
A motivation:
- To avoid some relocations for XIP, I want to use xtensa PC-relative
call instructions, which can only reach ~512KB.
Using `CHECK_BULK_MEMORY_OVERFLOW(addr + offset, n, maddr)` to do the
boundary check may encounter integer overflow in `addr + offset`, change to
use `CHECK_MEMORY_OVERFLOW(n)` instead, which converts `addr` and `offset`
to uint64 first and then add them to avoid integer overflow.
With this approach we can omit using memset() for the newly allocated memory
therefore the physical pages are not being used unless touched by the program.
This also simplifies the implementation.
This PR adds the initial support for WASM exception handling:
* Inside the classic interpreter only:
* Initial handling of Tags
* Initial handling of Exceptions based on W3C Exception Proposal
* Import and Export of Exceptions and Tags
* Add `cmake -DWAMR_BUILD_EXCE_HANDLING=1/0` option to enable/disable
the feature, and by default it is disabled
* Update the wamr-test-suites scripts to test the feature
* Additional CI/CD changes to validate the exception spec proposal cases
Refer to:
https://github.com/bytecodealliance/wasm-micro-runtime/issues/1884587513f3c68bebfe9ad759bccdfed8
Signed-off-by: Ricardo Aguilar <ricardoaguilar@siemens.com>
Co-authored-by: Chris Woods <chris.woods@siemens.com>
Co-authored-by: Rene Ermler <rene.ermler@siemens.com>
Co-authored-by: Trenner Thomas <trenner.thomas@siemens.com>
While we used a different approach for poll_oneoff [1],
the implementation works only when the poll list includes
an absolute clock event. That is, if we have a thread which is
polling on descriptors without a timeout, we fail to terminate
the thread.
This commit fixes it by applying wasm_runtime_begin_blocking_op
to poll as well.
[1] https://github.com/bytecodealliance/wasm-micro-runtime/pull/1951
Possible alternatives:
* Make wasm_cluster_destroy_spawned_exec_env take two exec_env.
One for wasm execution and another to specify the target to destroy.
* Make execute functions to switch exec_env as briefly discussed in
https://github.com/bytecodealliance/wasm-micro-runtime/pull/2047
Check whether the arguments are NULL before calling bh_hash_map_find,
or lots of "HashMap find elem failed: map or key is NULL" warnings may
be dumped. Reported in #3053.
