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

Move *mut dyn VMStore out of VMContext #10040

Merged

Conversation

alexcrichton
Copy link
Member

There's no need for this type to be accessible from compiled code, so store and manage it entirely from Rust instead.

@alexcrichton alexcrichton requested a review from a team as a code owner January 17, 2025 19:42
@alexcrichton alexcrichton requested review from fitzgen and removed request for a team January 17, 2025 19:42
@github-actions github-actions bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Jan 17, 2025
Copy link
Member

@fitzgen fitzgen left a comment

Choose a reason for hiding this comment

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

Nice

@alexcrichton alexcrichton force-pushed the move-out-of-vmcontext branch from cd6c737 to da3cd01 Compare January 21, 2025 19:51
@alexcrichton alexcrichton added this pull request to the merge queue Jan 21, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jan 21, 2025
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request Jan 21, 2025
This commit fixes a crash found in the CI of bytecodealliance#10040. That PR itself
isn't the fault per-se but rather uncovered a preexisting issue on
riscv64. According to riscv64's ABI docs it looks like arguments are all
expected to be sign-extended, whereas currently in Wasmtime all host
signatures are zero-extended on all platforms. This commit applies two
changes to fix this:

* A new `TargetIsa::default_argument_extension` method was added which
  is now used instead of unconditionally using `uext` to apply to all
  arguments/results.

* While I was here I went ahead and split apart things where the wasm
  signature of a builtin doesn't use `uext` or `sext`. The host
  signature still does, however, which means that any extension
  necessary happens in the trampoline we generate per-libcall as opposed
  to at all callsites.

I'm not certain that all platforms require `uext` but I've left the
`TargetIsa` implementation as `uext` for now with a comment explaining
why. Currently the only non-`uext` platforms are riscv64, which is
`sext` to fix the issue from bytecodealliance#10040, and Pulley which is "none" as
things work differently there.
@alexcrichton
Copy link
Member Author

I believe the crashes in CI are due to #10069, so I'm going to re-queue this once that merges (didn't want to mix that up in over here)

github-merge-queue bot pushed a commit that referenced this pull request Jan 23, 2025
* Fix argument extension on riscv64 for Wasmtime builtins

This commit fixes a crash found in the CI of #10040. That PR itself
isn't the fault per-se but rather uncovered a preexisting issue on
riscv64. According to riscv64's ABI docs it looks like arguments are all
expected to be sign-extended, whereas currently in Wasmtime all host
signatures are zero-extended on all platforms. This commit applies two
changes to fix this:

* A new `TargetIsa::default_argument_extension` method was added which
  is now used instead of unconditionally using `uext` to apply to all
  arguments/results.

* While I was here I went ahead and split apart things where the wasm
  signature of a builtin doesn't use `uext` or `sext`. The host
  signature still does, however, which means that any extension
  necessary happens in the trampoline we generate per-libcall as opposed
  to at all callsites.

I'm not certain that all platforms require `uext` but I've left the
`TargetIsa` implementation as `uext` for now with a comment explaining
why. Currently the only non-`uext` platforms are riscv64, which is
`sext` to fix the issue from #10040, and Pulley which is "none" as
things work differently there.

* Update test expectations
There's no need for this type to be accessible from compiled code, so
store and manage it entirely from Rust instead.
@alexcrichton alexcrichton force-pushed the move-out-of-vmcontext branch from da3cd01 to a5b0efd Compare January 23, 2025 15:44
@alexcrichton alexcrichton added this pull request to the merge queue Jan 23, 2025
Merged via the queue into bytecodealliance:main with commit c3559d4 Jan 23, 2025
39 checks passed
@alexcrichton alexcrichton deleted the move-out-of-vmcontext branch January 23, 2025 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wasmtime:api Related to the API of the `wasmtime` crate itself
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants