Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid memory import failure when WASI threads enabled #2893

Merged

Conversation

eloparco
Copy link
Contributor

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.

source

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) source 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.

@eloparco eloparco force-pushed the eloparco/import-memory-wasi-threads branch 2 times, most recently from ff4e425 to be5cd05 Compare December 10, 2023 23:09
@eloparco eloparco force-pushed the eloparco/import-memory-wasi-threads branch from be5cd05 to 4ebd495 Compare December 11, 2023 09:05
Copy link
Contributor

@wenyongh wenyongh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@wenyongh wenyongh merged commit 4aee3cf into bytecodealliance:main Dec 11, 2023
393 checks passed
victoryang00 pushed a commit to victoryang00/wamr-aot-gc-checkpoint-restore that referenced this pull request 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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants