do not return __WASI_ERRNO_xxx error code where 0/-1 is more appropriate.
most of them were not harmful because the value of
__WASI_ERRNO_SUCCESS is 0.
the one with __WASI_ERRNO_NOPROTOOPT in socket() is
a user-visible bug.
tested with wamr-wasi-extensions/samples/socket-tcp-udp.
cf. https://github.com/bytecodealliance/wasm-micro-runtime/issues/4474
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.
* introduce wasm_runtime_instantiate_ex2
at this point, just a slightly inefficiant functionality
equivalent of wasm_runtime_instantiate_ex.
however, unlike wasm_runtime_instantiate_ex, this one is designed
to be extendable without breaking the user-visible ABI.
because the definition of InstantiationArgs2 is not exposed to
users, we can safely add new members to it.
this commit also makes wasm_runtime_instantiate_ex a wrapper
of wasm_runtime_instantiate_ex2.
if this goes well, maybe it's a good idea to apply a similar
pattern to RuntimeInitArgs, LoadArgs, SharedHeapInitArgs, etc.
i started with InstantiationArgs just because i happen to have
a need to extend it for wasi-nn.
cf.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/4364https://github.com/bytecodealliance/wasm-micro-runtime/issues/4331
* product-mini/platforms/posix: use wasm_runtime_instantiate_ex2
as tested by core/iwasm/libraries/wasi-nn/test/test_tensorflow.c,
the legacy "wasi_nn" abi uses the number of fp32 for get_output.
because these backends don't implement the abi, bail out explicitly
in build time.
cf.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/4376
* return valid graph and execution context instead of using stack garbage.
(always 0 for now because we don't implement multiple graph/context
for this backend.)
* validate user-given graph and execution context values. reject
invalid ones.
* Revert "Improve spec test execution by adding retry logic for transient errors (#4393)"
This reverts commit 64cafaff1e.
* Revert "Add error handling for sgx ci (#4222)"
This reverts commit 8ad47897d1.
* wamr-wasi-extensions: separate test scripts
also, allow to specify the prefix directory.
for the convenience of the CI.
* CI: build wamr-wasi-extensions
fragments are copied from compilation_on_macos.yml.
(thus intel copyright notice)
the motivations:
* make the actual input size available to the backends.
(currently the backends have to make a guess from shape/type.)
* make the host logic look a bit similar to wasi_ephemeral_nn.
this is a backend api/abi change.
it should be byte size, not the number of (fp32) values.
i'm ambivalent about how to deal with the compatibility for
the legacy wamr-specific "wasi_nn". for now, i avoided changing it.
(so that existing tests using the legacy abi, namely test_tensorflow.c
and test_tensorflow_quantized.c, passes as they are.)
if we have any users who still want to use the legacy abi,
i suppose they consider the compatibility is more important
than the consistency with other backends.
cf. https://github.com/bytecodealliance/wasm-micro-runtime/issues/4376
* wasi-nn: fix context lifetime issues
use the module instance context api instead of trying to roll
our own with a hashmap. this fixes context lifetime problems mentioned in
https://github.com/bytecodealliance/wasm-micro-runtime/issues/4313.
namely,
* wasi-nn resources will be freed earlier now. before this change,
they used to be kept until the runtime shutdown. (wasm_runtime_destroy)
after this change, they will be freed together with the associated
instances.
* wasm_module_inst_t pointer uniqueness assumption (which is wrong
after wasm_runtime_deinstantiate) was lifted.
as a side effect, this change also makes a context shared among threads
within a cluster. note that this is a user-visible api/abi breaking change.
before this change, wasi-nn "handles" like wasi_ephemeral_nn_graph were
thread-local. after this change, they are shared among threads within
a cluster, similarly to wasi file descriptors. spec-wise, either behavior
should be ok simply because wasi officially doesn't have threads yet.
althogh i feel the latter semantics is more intuitive, if your application
depends on the thread-local behavior, this change breaks your application.
tested with wamr-wasi-extensions/samples/nn-cli, modified to
call each wasi-nn operations on different threads. (if you are
interested, you can find the modification at
https://github.com/yamt/wasm-micro-runtime/tree/yamt-nn-wip-20250619.)
cf.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/4313https://github.com/bytecodealliance/wasm-micro-runtime/issues/2430
* runtime_lib.cmake: enable WAMR_BUILD_MODULE_INST_CONTEXT for wasi-nn
as we do for wasi (WAMR_BUILD_LIBC_WASI)
currently this is not necessary because context (WASINNContext) is
local to instance. (wasm_module_instance_t)
i plan to make a context shared among instances in a cluster when
fixing https://github.com/bytecodealliance/wasm-micro-runtime/issues/4313.
this is a preparation for that direction.
an obvious alternative is to tweak the module instance context APIs
to allow declaring some kind of contexts instance-local. but i feel,
in this particular case, it's more natural to make "wasi-nn handles"
shared among threads within a "process".
note that, spec-wise, how wasi-nn behaves wrt threads is not defined
at all because wasi officially doesn't have threads yet. i suppose, at
this point, that how wasi-nn interacts with wasi-threads is something
we need to define by ourselves, especially when we are using an outdated
wasi-nn version.
with this change, if a thread attempts to access a context while
another thread is using it, we simply make the operation fail with
the "busy" error. this is intended for the mimimum serialization to
avoid problems like crashes/leaks/etc. this is not intended to allow
parallelism or such.
no functional changes are intended at this point yet.
cf.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/4313https://github.com/bytecodealliance/wasm-micro-runtime/issues/2430
copied from the linux version.
i'm a bit skeptical with this workaround though.
it might be simpler to prohibit the use of wamr api in these
shared libraries. after all, what these libraries do is nothing
specific to wasm.
an example application with flexible cli options which
aims to allow us to perform any wasi-nn operations.
eg.
```
--load-graph=file=fixture/model.xml,file=fixture/model.bin,id=graph
--init-execution-context=graph-id=graph,id=ctx
--set-input=file=fixture/tensor.bgr,context-id=ctx,dim=1,dim=3,dim=224,dim=224
--compute=context-id=ctx
--get-output=context-id=ctx,file=output.bin
```
as wasi-nn doesn't have these concepts, the best we can do without
risking breaking certain applications here is to pass through tensors
as they are.
this matches wasmtime's behavior.
tested with:
* wasmtime classification-example
(with this change, this example fails on tensor size mismatch
instead of implicitly resizing it.)
* license-plate-recognition-barrier-0007, a converted version
with non-fp32 output. [1]
(with this change, this model outputs integers as expected.)
[1] https://github.com/openvinotoolkit/open_model_zoo/tree/cd7ebe313b69372763e76b82e5d24935308fece4/models/public/license-plate-recognition-barrier-0007
- wasi_nn.h: make this compatible with wasi_ephemeral_nn
cf. https://github.com/bytecodealliance/wasm-micro-runtime/issues/4323
- fix WASM_ENABLE_WASI_EPHEMERAL_NN build
this structure is used by host logic as well.
ideally definitions for wasm and host should be separated.
until it happens, check __wasm__ to avoid the breakage.
* this enum is (@witx tag u8) in witx
* it seems that some wasm modules actually use non-zero padding
and cause errors
* it's a bad practice to use C enum for ABI description anyway
sync with a more appropriate version of the definitions.
as we use the "wasi_ephemeral_nn", which is p1-based, it seems
more appropriate to use definitions from witx, not wit.
it's a bit unfortunate p2-based wasi-nn made gratuitous changes
like this from p1.
note: this is an ABI change.
it seems meaningless and quite confusing to access a table with
two aliases ("lookup" and "backends") within a function.
no functional changes are intended.
This partly reverts "Cmake improvements".
(https://github.com/bytecodealliance/wasm-micro-runtime/pull/4076)
Recently we changed the location to install public headers.
For example,
Old: include/wasm_export.h
New: include/iwasm/wasm_export.h
For cmake-based user applications using find_package(iwasm),
the cmake package, namely target_include_directories(INSTALL_INTERFACE),
is expected to add necessary compiler options like -isystem automatically.
(See samples/printversion for an example of such user applications.)
However, in reality, not every user application uses cmake.
This commit reverts the location to install public headers
for now, to avoid breakage for non-cmake user applications.
In case we want to re-apply the location change in future,
we should better communicate to the users. (eg. document
migration proceduces in release notes.)
Fixes: https://github.com/bytecodealliance/wasm-micro-runtime/issues/4290
References:
https://cmake.org/cmake/help/latest/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES.html
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:
https://github.com/WebAssembly/extended-const/blob/8d4f6aa2b00a8e7c0174410028625c6a176db8a1/test/core/data.wast#L184-L187
- 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.)
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.
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)
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. https://github.com/llvm/llvm-project/commit/41895843b5915bb78e9d02aa711fa10f7174db43
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
This fixes link errors seen on my environment.
(macOS 15.2, x86-64, Xcode 16.2)
Tested as:
```
mkdir b
cd b
cmake -D WAMR_BUILD_JIT=1 -D LLVM_DIR=/usr/local/opt/llvm@19/lib/cmake/llvm ..
make
```
* Bump AOT_CURRENT_VERSION for WAMR 2.x (gc, memory64)
Maybe it's too late because we have already made a few releases
since then.
But this might still help users who haven't upgraded to WAMR 2.x yet.
Also, for the purpose of the versioning, it's safer to bump
needlessly than missing necessary bumps.
Fixes https://github.com/bytecodealliance/wasm-micro-runtime/issues/3837
* test-tools/aot-analyzer/include/config.h: bump AOT_CURRENT_VERSION
I'm not sure we want to use C99 %tu here.
While C99 %zu is more widely used in WAMR, %tu is rare (if any)
and I'm not sure if it's ubiquitously implemented in platforms
we support.
For JIT, we naturally use mach-o on macOS, where the section name
we currently use is not valid and ends up with the errors like:
```
LLVM ERROR: Global variable '__orc_lcl.aot_stack_sizes.0' has an invalid section specifier '.aot_stack_sizes': mach-o section specifier requires a segment and section separated by a comma.
```
Because the dedicated section is not necessary for JIT,
this commit simply stops using it.
Fixes: https://github.com/bytecodealliance/wasm-micro-runtime/issues/3730
