to run product-mini/platforms/zephyr/simple and
product-mini/platforms/zephyr/user-mode
Construct a T2 (star topology) for the current smoke test. This is not the
final topology, and we may modify it once we determine the optimal
configuration.
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
* Follow-up to PR #4300: prevent potential overflow
PR #4300 introduced the rationale for validating heap_type.
This patch moves the validation before the computation of
type1 to prevent potential overflow.
Propose two enhancements:
- Shared heap created from preallocated memory buffer: The user can create a shared heap from a pre-allocated buffer and see that memory region as one large chunk; there's no need to dynamically manage it(malloc/free). The user needs to make sure the native address and size of that memory region are valid.
- Introduce shared heap chain: The user can create a shared heap chain, from the wasm app point of view, it's still a continuous memory region in wasm app's point of view while in the native it can consist of multiple shared heaps (each of which is a continuous memory region). For example, one 500MB shared heap 1 and one 500 MB shared heap 2 form a chain, in Wasm's point of view, it's one 1GB shared heap.
After these enhancements, the data sharing between wasm apps, and between hosts can be more efficient and flexible. Admittedly shared heap management can be more complex for users, but it's similar to the zero-overhead principle. No overhead will be imposed for the users who don't use the shared heap enhancement or don't use the shared heap at all.
* 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.
It is reported as "Multiplication result converted to larger type".
And "Multiplication result may overflow 'Type A' before it is
converted to 'Type B'." Type A is a larger type than Type B.
Since the conversion applies after the multiplication, arithmetic
overflow may still occur.
> The rule flags every multiplication of two non-constant integer expressions
> that is (explicitly or implicitly) converted to a larger integer type. The
> conversion is an indication that the expression would produce a result that
> would be too large to fit in the smaller integer type.
* 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)
