Skip to content

Configure async task context on realloc calls#13949

Merged
alexcrichton merged 3 commits into
bytecodealliance:mainfrom
alexcrichton:reset-realloc-context
Jul 24, 2026
Merged

Configure async task context on realloc calls#13949
alexcrichton merged 3 commits into
bytecodealliance:mainfrom
alexcrichton:reset-realloc-context

Conversation

@alexcrichton

Copy link
Copy Markdown
Member

This commit is an implementation of WebAssembly/component-model#680 which is a semantic change for invocations of the realloc canonical ABI option. Previously when this function was invoked the configured context-storage was whatever happened to run last in the store and in general wasn't well-defined. Additionally the context of the thread being run in was whatever happened to run last. The goal of the upstream spec change, and this commit, is to fully define what happens in this situation. Specifically:

  • Invocations of realloc always start with context slots set to 0.
  • The thread.index intrinsics, part of the component-model-threading proposal, is now no longer exempt from may-leave checks.

These changes combined mean that it's not actually possible for realloc to witness anything about its thread identity. This means that we don't actually have to allocate anything, all that's necessary is to save/restore context around invocation of cabi_realloc.

While this is a breaking change it's not expected to be observable in the ecosystem. This only affects context slots which are primarily only used for the WASIp3 ABI as the stack pointer and TLS base. There is no shipping WASIp3 target anywhere right now, so this breakage should not be observable.

This commit is an implementation of WebAssembly/component-model#680
which is a semantic change for invocations of the `realloc` canonical
ABI option. Previously when this function was invoked the configured
context-storage was whatever happened to run last in the store and in
general wasn't well-defined. Additionally the context of the thread
being run in was whatever happened to run last. The goal of the upstream
spec change, and this commit, is to fully define what happens in this
situation. Specifically:

* Invocations of `realloc` always start with `context` slots set to 0.
* The `thread.index` intrinsics, part of the component-model-threading
  proposal, is now no longer exempt from may-leave checks.

These changes combined mean that it's not actually possible for
`realloc` to witness anything about its thread identity. This means that
we don't actually have to allocate anything, all that's necessary is to
save/restore context around invocation of `cabi_realloc`.

While this is a breaking change it's not expected to be observable in
the ecosystem. This only affects `context` slots which are primarily
only used for the WASIp3 ABI as the stack pointer and TLS base. There is
no shipping WASIp3 target anywhere right now, so this breakage should
not be observable.
@alexcrichton
alexcrichton requested review from a team as code owners July 23, 2026 22:57
@alexcrichton
alexcrichton requested review from cfallin and removed request for a team July 23, 2026 22:57
bail!("realloc return: beyond end of memory")
}

*self.store.0.vm_store_context_mut().component_context_mut() = orig_context;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Do we need a drop-guard to restore the context if an error is returned (e.g. the bail! above), or are those always trap-cases I guess?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

We should be good in this case because once a component traps everything internally is inaccessible and no longer able to be seen by a guest. There's a fair number of locations in concurrent.rs that do this as well (don't restore on trap/panic) as well. I've added a comment now to that effect though for future readers

@alexcrichton
alexcrichton enabled auto-merge July 23, 2026 23:10
@alexcrichton
alexcrichton added this pull request to the merge queue Jul 23, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jul 23, 2026
@alexcrichton

Copy link
Copy Markdown
Member Author

Heh well @dicej maybe your Windows-specific failure wasn't Windows-specific after all (failing test on macOS)

@alexcrichton
alexcrichton added this pull request to the merge queue Jul 23, 2026
Merged via the queue into bytecodealliance:main with commit fb8c761 Jul 24, 2026
53 checks passed
@alexcrichton
alexcrichton deleted the reset-realloc-context branch July 24, 2026 00:11
pull Bot pushed a commit to eduardomourar/wasmtime that referenced this pull request Jul 24, 2026
* Update some required features for tests
* Flag `memory64.wast` as now-passing
* Temporarily allow `post-return.wast` to fail while bytecodealliance#13949 and
  WebAssembly/component-model#680 are being aligned.
* Fix a debug assert tripping erroneously in an async `subtask.cancel`
  intrinsic.
alexcrichton added a commit to alexcrichton/wasi-libc that referenced this pull request Jul 24, 2026
This commit is an update to the `cabi_realloc` export configured by
wasi-libc, specifically for wasip3 targets. The change here is to change
the entrypoint from a C function to a small assembly wrapper which
configures the stack pointer and TLS base before calling into C. This is
to account for the spec change in WebAssembly/component-model#680 where
`realloc` hooks are now going to be invoked with context slots set to 0.
This means that `cabi_realloc` runs with no stack, and this would
quickly abort in wasi-libc otherwise.

The change here is to, when the ABI is using `context` slots for the
stack pointer, have an assembly wrapper that configures a known-good
stack and TLS block for `cabi_realloc` to use. Once configured the
normal C-based `cabi_realloc` routine runs. This is tested against
bytecodealliance/wasmtime#13949 to ensure it works on the p3 target
with/without coop threading and before/after that Wasmtime change.
yagehu pushed a commit to yagehu/wasmtime-x that referenced this pull request Jul 26, 2026
* Configure async task context on `realloc` calls

This commit is an implementation of WebAssembly/component-model#680
which is a semantic change for invocations of the `realloc` canonical
ABI option. Previously when this function was invoked the configured
context-storage was whatever happened to run last in the store and in
general wasn't well-defined. Additionally the context of the thread
being run in was whatever happened to run last. The goal of the upstream
spec change, and this commit, is to fully define what happens in this
situation. Specifically:

* Invocations of `realloc` always start with `context` slots set to 0.
* The `thread.index` intrinsics, part of the component-model-threading
  proposal, is now no longer exempt from may-leave checks.

These changes combined mean that it's not actually possible for
`realloc` to witness anything about its thread identity. This means that
we don't actually have to allocate anything, all that's necessary is to
save/restore context around invocation of `cabi_realloc`.

While this is a breaking change it's not expected to be observable in
the ecosystem. This only affects `context` slots which are primarily
only used for the WASIp3 ABI as the stack pointer and TLS base. There is
no shipping WASIp3 target anywhere right now, so this breakage should
not be observable.

* Fix conditional builds

* Add a note about restoration
yagehu pushed a commit to yagehu/wasmtime-x that referenced this pull request Jul 26, 2026
* Update some required features for tests
* Flag `memory64.wast` as now-passing
* Temporarily allow `post-return.wast` to fail while bytecodealliance#13949 and
  WebAssembly/component-model#680 are being aligned.
* Fix a debug assert tripping erroneously in an async `subtask.cancel`
  intrinsic.
alexcrichton added a commit to WebAssembly/wasi-libc that referenced this pull request Jul 27, 2026
This commit is an update to the `cabi_realloc` export configured by
wasi-libc, specifically for wasip3 targets. The change here is to change
the entrypoint from a C function to a small assembly wrapper which
configures the stack pointer and TLS base before calling into C. This is
to account for the spec change in WebAssembly/component-model#680 where
`realloc` hooks are now going to be invoked with context slots set to 0.
This means that `cabi_realloc` runs with no stack, and this would
quickly abort in wasi-libc otherwise.

The change here is to, when the ABI is using `context` slots for the
stack pointer, have an assembly wrapper that configures a known-good
stack and TLS block for `cabi_realloc` to use. Once configured the
normal C-based `cabi_realloc` routine runs. This is tested against
bytecodealliance/wasmtime#13949 to ensure it works on the p3 target
with/without coop threading and before/after that Wasmtime change.
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.

2 participants