memory import name #33
Comments
|
Seems reasonable yes, this limitation can always be relaxed/widened later if we have things like multi-memory, but we are not there yet. |
wenyongh
pushed a commit
to bytecodealliance/wasm-micro-runtime
that referenced
this issue
Dec 11, 2023
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: WebAssembly/wasi-threads#33, so this PR only avoids treating the submodule dependency not being found as a failure.
victoryang00
pushed a commit
to victoryang00/wamr-aot-gc-checkpoint-restore
that referenced
this issue
May 27, 2024
…iance#2893) 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: WebAssembly/wasi-threads#33, so this PR only avoids treating the submodule dependency not being found as a failure.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
currently it's just said:
so, a typical implementation would automatically create shared memories to satisfy all shared memory imports.
eg. https://github.com/yamt/toywasm/blob/c674b4edf25ff6880d41d3bd255ca6e468aec0df/lib/shared_memory.c#L20.
i feel it's neater if we make it a bit more controlled.
eg. only create a memory for the shared memory import from a specific module/name, eg.
wasi:memory.how do you think?
The text was updated successfully, but these errors were encountered: