* Empty names are spec-wise valid.
* As we ignore unknown custom sections anyway, it's safe to
accept empty names here.
* Currently, the problem is not exposed on our CI because
the wabt version used there is a bit old.
For shared memory, runtime should get the memories pointer from
module_inst first, then get memory instance from memories array,
and then get the fields of the memory instance.
Support new a wasm_config_t, set allocation and linux_perf_support
options to it, and then pass it to wasm_engine_new_with_config to
new an engine with private configuration.
The JSON evidence is allocated on the module instance heap, but no API
was given to dispose of this memory buffer. The sample mentions using
the function free, which behaves differently depending on the
execution context.
This fix provides a new function called librats_dispose_evidence_json,
enabling freeing the JSON evidence directly from the Wasm app.
Change WASMMemoryInstance's field is_shared_memory's type from bool
to uint8 whose size is fixed, so as to make WASMMemoryInstance's size
and layout fixed and not break AOT ABI.
See discussion in https://github.com/bytecodealliance/wasm-micro-runtime/pull/2682.
The popped reachable block may be if block whose else branch hasn't been
translated, and should push the params for the else block if there are.
And use LLVMDisposeMessage to free memory allocated in is_win_platform.
Currently, `data.drop` instruction is implemented by directly modifying the
underlying module. It breaks use cases where you have multiple instances
sharing a single loaded module. `elem.drop` has the same problem too.
This PR fixes the issue by keeping track of which data/elem segments have
been dropped by using bitmaps for each module instances separately, and
add a sample to demonstrate the issue and make the CI run it.
Also add a missing check of dropped elements to the fast-jit `table.init`.
Fixes: https://github.com/bytecodealliance/wasm-micro-runtime/issues/2735
Fixes: https://github.com/bytecodealliance/wasm-micro-runtime/issues/2772
CryptGenRandom is deprecated by Microsoft and may be removed in future
releases. They recommend to use the next generation API instead. See
https://learn.microsoft.com/en-us/windows/win32/seccng/cng-portal for
more details. Also, refactor the random functions to return error codes
rather than aborting the program if they fail.
Error is reported when executing `wamrc --target=thumb -o <aot_file> <wasm_file>`:
```
LLVM ERROR: failed to perform tail call elimination on a call site marked musttail
Aborted (core dumped)
```
Set `abi` to "gnu" for the bare-metal target when `abi` is NULL,
or the below `bh_assert` and `bh_memcpy` may deference a NULL
pointer. Error is reported when running wamrc compiled with
`cmake .. -DCMAKE_BUILD_TYPE=Debug`:
```
core/iwasm/compilation/aot_llvm.c:2584:13: runtime error:
null pointer passed as argument 1, which is declared to never be null
```
Add an extra argument `os_file_handle file` for `os_mmap` to support
mapping file from a file fd, and remove `os_get_invalid_handle` from
`posix_file.c` and `win_file.c`, instead, add it in the `platform_internal.h`
files to remove the dependency on libc-wasi.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Returning uint16 from WASI functions is technically correct. However,
the smallest integer type in WASM is int32 and since we don't guarantee
that the upper 16 bits of the result are zero'ed, it can result in
tricky bugs if the language SDK being used in the WASM app does not cast
back immediately to uint16. To prevent this, we directly return uint32
instead, so that the result is well-defined as a 32-bit number.
Set the vendor-sys of bare-metal targets to "-unknown-none-",
and currently only add "thumbxxx" to the bare-metal target list.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
The commit fa5e9d72b0 ("Abstract POSIX filesystem functions") introduces
the build warning:
./core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/posix.c: In function ‘fd_object_release’:
./core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/posix.c:545:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
545 | if (os_is_dir_stream_valid(&fo->directory.handle)) {
| ^
./core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/posix.c:549:13: note: here
549 | default:
| ^~~~~~~
Refer to the commit fb4afc7ca4 ("Apply clang-format for core/iwasm compilation and libraries"),
add one line "// Fallthrough." to make compiler happy.
Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
UWP apps do not have a console attached so any output to stdout/stderr
is lost. Therefore, provide a default BH_VPRINTF in that case for debug
builds which redirects output to the debugger.
Most of the WASI filesystem tests require at least creating/deleting a
file to test filesystem functionality so some additional filesystem APIs
have been implemented on Windows so we can test what has been
implemented so far. For those WASI functions which haven't been
implemented, we skip the tests. These will be implemented in a future PR
after which we can remove the relevant filters.
Additionally, in order to run the WASI socket and thread tests, we need
to install the wasi-sdk in CI and build the test source code prior to
running the tests.
`jit_reg_is_const_val` only checks whether the register is a const register and
the const value is stored in the register.
Should use `jit_reg_is_const` instead in the front end.
Reported in #2710.
- Fix potential invalid push param phis and add incoming phis to a un-existed basic block
- Fix potential invalid shift count int rotl/rotr opcodes
- Resize memory_data_size to UINT32_MAX if it is 4G when hw bound check is enabled
- Fix negative linear memory offset is used for 64-bit target it is const and larger than INT32_MAX
To run it locally:
```bash
export TSAN_OPTIONS=suppressions=<path_to_tsan_suppressions.txt>
./test_wamr.sh <your flags> -T tsan
```
An example for wasi-threads would look like:
```bash
export TSAN_OPTIONS=suppressions=<path_to_tsan_suppressions.txt>
./test_wamr.sh -w -s wasi_certification -t fast-interp -T tsan
```
Split memory instance's field `uint32 ref_count` into `bool is_shared_memory`
and `uint16 ref_count`, and lock the memory only when `is_shared_memory`
flag is true, no need to acquire a lock for non-shared memory when shared
memory feature is enabled.
Avoid repeatedly initializing the shared memory data when creating the child
thread in lib-pthread or lib-wasi-threads.
Add shared memory lock when accessing some fields of the memory instance
if the memory instance is shared.
Init shared memory's memory_data_size/memory_data_end fields according to
the current page count but not max page count.
Add wasm_runtime_set_mem_bound_check_bytes, and refine the error message
when shared memory flag is found but the feature isn't enabled.
Fixes the Cosmopolitan Libc platform attempting to use `/dev/urandom`
on operating systems that do not have it.
Signed-off-by: G4Vi <gavin@dylibso.com>
This patch enables mapping host directories to guest directories by parsing
the `map_dir_list` argument in API `wasm_runtime_init_wasi` for libc-wasi. It
follows the format `<guest-path>::<host-path>`.
It also adds argument `--map-dir=<guest::host>` argument for `iwasm`
common line tool, and allows to add multiple mappings:
```bash
iwasm --map-dir=<guest-path1::host-path1> --map-dir=<guest-path2::host-path2> ...
```
When labels-as-values is enabled in a target which doesn't support
unaligned address access, 16-bit offset is used to store the relative
offset between two opcode labels. But it is a little small and the loader
may report "pre-compiled label offset out of range" error.
Emitting 32-bit data instead to resolve the issue: emit label address in
32-bit target and emit 32-bit relative offset in 64-bit target.
See also:
https://github.com/bytecodealliance/wasm-micro-runtime/issues/2635
