some getaddrinfo implementations sometimes return results with
ai_protocol=0.
cf. https://github.com/apache/nuttx/issues/16693
standard-wise, i couldn't find anything about ai_protocol in
susv4-2018 except the following text:
> The fields ai_family, ai_socktype, and ai_protocol shall be usable
> as the arguments to the socket() function to create a socket suitable
> for use with the returned address.
because ai_protocol is usually merely used to feed socket() and
socket() usually accepts 0, it's probably standard-wise ok for
getaddrinfo to return ai_protocol=0.
the major implementations of getaddrinfo (eg. kame) seem to return
specific values like ai_protocol=IPPROTO_TCP though.
anyway, for the purpose of this function, there is little point to
be strict on the host getaddrinfo behavior. this commit just relaxes
the check to be friendly to those getaddrinfo implementations.
* initialize WASI stdio handles to invalid for better error handling
* implement os_invalid_raw_handle function for consistent invalid handle representation
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>
For boundary checking, WAMR calls `pthread_attr_np`, which is
unfortunately quite slow on Linux when not called on the main thread
(see https://github.com/bytecodealliance/wasm-micro-runtime/issues/3966
for discussion).
This change moves the cost of stack bounds checking earlier in the
wasm_exec_env creation process. The idea is that it's perhaps better to
pay the price when creating the execution environment rather than in the
first function call.
The original code is left in place inside
`call_wasm_with_hw_bound_check` in case the `wasm_exec_env` is created
via `wasm_runtime_spawn_exec_env`.
By default, the project() CMake command defaults to C and C++. [1]
Therefore, CMake might perform tests for both C and C++ compilers as
part of the configuration phase.
However, this has the consequence of the configuration phase to fail if
the system does not have a C++ toolchain installed, even if C++ is not
really used by the top-level project under the default settings.
Some configurations might still require a C++ toolchain, so
enable_language is selectively called under such circumstances.
[1]: https://cmake.org/cmake/help/latest/command/project.html
- Clear some compile warnings
- Fix some typos
- Fix llvm LICENSE link error
- Remove unused aot file and binarydump bin
- Add checks when loading AOT exports
The default iwasm building in Windows MSVC enables libc-uvwasi because
libc-wasi isn't supported at the beginning. Since libc-wasi had been refactored
and is supported in Windows msys2 building, and libc-wasi supports more
functionalities(e.g. sockets) than libc-uvwasi, this PR fixes some issues to
enable libc-wasi in windows MSVC buidlings.
- Only retry on EAGAIN, ENOMEM or EINTR.
- On EINTR, don't count it against the retry budget, just keep retrying.
EINTR can happen in bursts.
- Log the errno on failure, and don't conditionalize that logging on
BH_ENABLE_TRACE_MMAP. In other parts of the code, error logging is not
conditional on that define, while turning on that tracing define makes
things overly verbose.
Some host environment may also create an signal alternate stack and access
it after the wasm runtime exits, the runtime should backup the stack info and
restore it before thread exits.
The issue was found in golang:
```
signal 23 received on thread with on signal stack
fatal error: non-Go code disabled signaltstack
```
Add support for the [Zephyr Usermode](https://docs.zephyrproject.org/latest/kernel/usermode/index.html)
to the Zephyr port.
The following changes are applied:
- Fix `signbit`, check if it is defined already and only implement it, if not
- Introduce `sys_mutex` and `sys_sem` in favour of `k_mutex` and `k_sem`, when `CONFIG_USERMODE` is enabled
- Remove the installation of the `_stdout_hook_iwasm()` when `CONFIG_USERMODE` is enabled, otherwise this
causes MPU errors since the std hook is in the kernel space
- Add a thread name for debugging
The `os_mremap` and `os_getpagesize` were missing in the `core/shared/platform/riot`
and were preventing RIOT from compiling if using WAMR v2.x.x. This PR is adding
both functions and should allow RIOT to update WAMR version to v2.x.x.
Signed-off-by:: mewen.berthelot <mewen.berthelot@orange.com>
This change supports building with `-DWAMR_BUILD_LIBC_WASI=0` and
`-DWAMR_BUILD_DEBUG_INTERP=1`, otherwise the os_socket_* functions
will be undefined.
Although I don't know what exactly the esp32s3 rom version of memset is,
it seems that the current code crashes only with a small "len". I guess
it changes the logic depending on the size.
Anyway, it's safer to use dbus here.
Add WASI support for esp-idf platform:
1. add Kconfig and cmake scripts
2. add API "openat" when using littlefs
3. add clock/rwlock/file/socket OS adapter
This PR fixes a readir for posix. readdir is not working correctly in rust.
The current WAMR's readdir implementation for posix is, if readdir returns 0,
it will exit with an error. But posix readdir returns 0 at the end of the directory.
To handle this correctly, if readdir returns 0, it should only raise an error if
errno has changed. We can reproduce it with the following rust code:
```rust
use std::fs;
fn main() {
let entries = fs::read_dir(".").unwrap();
for entry in entries {
println!("read_dir:{:?}", entry);
}
}
```
`posix_fadvise()` returns 0 on success and the errno on error. This
commit fixes the handling of the return value such that it does not
always succeeds.
Fixes#3322.
1. Fix API "futimens" and "utimensat" compiling error in different esp-idf version
2. Update component registry description file
ps. refer to PR #3296 on branch release/1.3x
For use with WAMR_BUILD_LIB_PTHREAD, add os_thread_detach,
os_thread_exit, os_cond_broadcast.
Signed-off-by: Maxim Kolchurin <maxim.kolchurin@gmail.com>
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
