In some scenarios there may be lots of callings to AOT/JIT functions from the
host embedder, which expects good performance for the calling process, while
in the current implementation, runtime calls the wasm_runtime_invoke_native
to prepare the array of registers and stacks for the invokeNative assemble code,
and the latter then puts the elements in the array to physical registers and
native stacks and calls the AOT/JIT function, there may be many data copying
and handlings which impact the performance.
This PR registers some quick AOT/JIT entries for some simple wasm signatures,
and let runtime call the entry to directly invoke the AOT/JIT function instead of
calling wasm_runtime_invoke_native, which speedups the calling process.
We may extend the mechanism next to allow the developer to register his quick
AOT/JIT entries to speedup the calling process of invoking the AOT/JIT functions
for some specific signatures.
On macOS, by default, the first 4GB is occupied by the pagezero.
While it can be controlled with link time options, as we are
an library, we usually don't have a control on how to link an
executable.
Add an API to set segue flags for wasm-c-api LLVM JIT mode:
```C
wasm_config_t *
wasm_config_set_segue_flags(wasm_config_t *config, uint32 segue_flags);
```
- Don't allocate the implicit/unused frame when calling the LLVM JIT function
- Don't set exec_env's thread handle and stack boundary in the recursive
calling from host, since they have been set in the first time calling
- Fix frame not freed in llvm_jit_call_func_bytecode
before the change, only support wasm app exit like:
```c
void *thread_routine(void *arg)
{
printf("Enter thread\n");
return NULL;
}
```
if call pthread_exit, it will crash:
```c
void *thread_routine(void *arg)
{
printf("Enter thread\n");
pthread_exit(NULL);
return NULL;
}
```
This commit lets both upstairs work correctly, test pass on stm32f103 mcu.
This PR addresses the issue with building the sgx-ra sample when the enclave under
the path product-mini/platforms/linux-sgx/enclave-sample is built beforehand.
When the enclave is built without librats ahead, an error occurs as the following
without the changes:
```bash
...
CP libvmlib.a <= /home/haoxuan/wasm-micro-runtime/samples/sgx-ra/build/libvmlib.a
/usr/local/bin/ld: libvmlib.a(lib_rats_wrapper.c.o): in function `librats_collect_wrapper':
lib_rats_wrapper.c:(.text.librats_collect_wrapper+0x4a): undefined reference to `wasm_runtime_get_module_hash'
collect2: error: ld returned 1 exit status
```
And refactor the original perf support
- use WAMR_BUILD_LINUX_PERF as the cmake compilation control
- use WASM_ENABLE_LINUX_PERF as the compiler macro
- use `wamrc --enable-linux-perf` to generate aot file which contains fp operations
- use `iwasm --enable-linux-perf` to create perf map for `perf record`
Allow to control built-in libraries for wamrc from command line options:
```bash
cmake -DWAMR_BUILD_LIBC_WASI=1/0
cmake -DWAMR_BUILD_LIBC_BUILTIN=1/0
cmake -DWAMR_BUILD_LIB_PTHREAD=1/0
cmake -DWAMR_BUILD_LIB_WASI_THREADS=1/0
```
And add some messages to show the status.
The host embedder may also want to terminate the wasm instance
for single-threading mode, and it should work by setting exception
to the wasm instance.
Loggers (e.g. glog) usually come with instrumentation to add timestamp
and other information when reporting. That results in the timestamp
being reported twice, making the output confusing.
According to the specification:
```
When instantiating a module which is expected to run
with `wasi-threads`, the WASI host must first allocate shared memories to
satisfy the module's imports.
```
Currently, if a test from the spec is executed while having the `multi-module`
feature enabled, WAMR fails with `WASM module load failed: unknown import`.
That happens because spec tests use memory like this:
`(memory (export "memory") (import "foo" "bar") 1 1 shared)`
and WAMR tries to find a registered module named `foo`.
At the moment, there is no specific module name that can be used to identify
that the memory is imported because using WASI threads:
https://github.com/WebAssembly/wasi-threads/issues/33,
so this PR only avoids treating the submodule dependency not being found
as a failure.
It's possible to set both `atim` and `atim_now` in the `fstflags`
parameter. Same goes for `mtin` and `mtim_now`. However, it's
ambiguous which time should be set in these two cases. This commit
checks this and returns `EINVAL`.
A wasm module can be either a command or a reactor, so it can export
either `_start` or `_initialize`. Currently, if a command module is run,
`iwasm` still looks for `_initialize`, resulting in the warning:
`can not find an export 0 named _initialize in the module`.
Change to look for `_initialize` only if `_start` not found to resolve the issue.
This fixes bug #2880. Zephyr 3.2 made changes to how headers are reference (see [release notes](https://docs.zephyrproject.org/latest/releases/release-notes-3.2.html)). Work item [49578](https://github.com/zephyrproject-rtos/zephyr/issues/49578) deprecated the old headers names.
The current WAMR codebase references these old headers, thus causing compile errors with
current versions of Zephyr.
This update adds #ifdefs around the header names. With this change, compiling with Zephyr 3.2.0
and above will use the new header files. Prior versions will use the existing code.
This commit adds a check to `fd_advise`. If the fd is a directory,
return `ebadf`. This brings iwasm in line with Wasmtime's behavior.
WASI folks have stated that fd_advise should not work on directories
as this is a Linux-specific behavior:
https://github.com/bytecodealliance/wasmtime/issues/6505#issuecomment-1574122949
