Use `TryBTreeMap` in the store's `ModuleRegistry` (#12846)

Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)

We currently do a store-wide state-change on all registered modules
when the "single stepping" flag c

Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)

We currently do a store-wide state-change on all registered modules
when the "single stepping" flag changes, patching in or out all
breakpoints. However, this design didn't account for modules
registered with the store *after* single-stepping is enabled (and new
modules may be registered any time an instantiation occurs). In
particular this is problematic when a debugger, e.g., sets the
single-step flag right at the beginning of execution of a "host main
function" that calls Wasm, before the main instantiation occurs.

This PR threads through the breakpoint state in the registration path,
with the narrow waist at `ModuleRegistry::register` which is the only
place where modules are added to the `LoadedCode`.

show more ...

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`

Instead of `anyhow::Error`.

This commit re-exports the `wasmtim

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`

Instead of `anyhow::Error`.

This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`
module, updates the prelude to include these new error-handling types, redirects
our top-level `wasmtime::{Error, Result}` re-exports to re-export
`wasmtime::error::{Error, Result}`, and updates various use sites that were
directly using `anyhow` to use the new `wasmtime` versions.

This process also required updating the component macro and wit-bindgen macro to
use the new error types instead of `anyhow`.

Part of https://github.com/bytecodealliance/wasmtime/issues/12069

* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense

* cargo fmt

* Move `crate::error::Thing` to `crate::Thing` where it makes sense

show more ...

Debug: implement breakpoints and single-stepping. (#12133)

* Debug: implement breakpoints and single-stepping.

This is a PR that puts together a bunch of earlier pieces (patchable
calls in #12061 a

Debug: implement breakpoints and single-stepping. (#12133)

* Debug: implement breakpoints and single-stepping.

This is a PR that puts together a bunch of earlier pieces (patchable
calls in #12061 and #12101, private copies of code in #12051, and all
the prior debug event and instrumentation infrastructure) to implement
breakpoints in the guest debugger.

These are implemented in the way we have planned in #11964: each
sequence point (location prior to a Wasm opcode) is now a patchable call
instruction, patched out (replaced with NOPs) by default. When patched
in, the breakpoint callsite calls a trampoline with the `patchable` ABI
which then invokes the `breakpoint` hostcall. That hostcall emits the
debug event and nothing else.

A few of the interesting bits in this PR include:
- Implementations of "unpublish" (switch permissions back to read/write
from read/execute) for mmap'd code memory on all our platforms.
- Infrastructure in the frame-tables (debug info) metadata producer and
parser to record "breakpoint patches".
- A tweak to the NOP metadata packaged with the `MachBuffer` to allow
multiple NOP sizes. This lets us use one 5-byte NOP on x86-64, for
example (did you know x86-64 had these?!) rather than five 1-byte
NOPs.

This PR also implements single-stepping with a global-per-`Store` flag,
because at this point why not; it's a small additional bit of logic to
do *all* patches in all modules registered in the `Store` when that flag
is enabled.

A few realizations for future work:
- The need for an introspection API available to a debugger to see the
modules within a component is starting to become clear; either that,
or the "module and PC" location identifier for a breakpoint switches
to a "module or component" sum type. Right now, the tests for this
feature use only core modules. Extending to components should not
actually be hard at all, we just need to build the API for it.
- The interaction between inlining and `patchable_call` is interesting:
what happens if we inline a `patchable_call` at a `try_call` callsite?
Right now, we do *not* update the `patchable_call` to a `try_call`,
because there is no `patchable_try_call`; this is fine in the Wasmtime
embedding in practice because we never (today!) throw exceptions from
a breakpoint handler. This does suggest to me that maybe we should
make patchability a property of any callsite, and allow try-calls to
be patchable too (with the same restriction about no return values as
the only restriction); but happy to discuss that one further.

* Add missing debug.wat disas test.

* Review feedback.

* Fix comment on `CodeMemory::text_mut`.

* Review feedback.

* Review feedback: abort process on failure to re-apply executable permissions.

* Implement icache flush for aarch64.

This appears to be necessary as we otherwise see a failure in CI on
macOS/aarch64 that is consistent with patched-in breakpoint calls still
being incorrectly cached after we remove them and republish the code.

There is a longstanding issue in #3310 tracking proper icache coherence
handling on aarch64. We implemented this for Linux with the `membarrier`
syscall but never did so for macOS. Maybe this is the first point at
which it matters, because code was always loaded at new addresses (hence
did not have coherence issues because nothing would have been cached)
previously.

prtest:full

* Review feedback: use `next_multiple_of`.

show more ...

Debug: create private code memories per store when debugging is enabled. (#12051)

* Debug: create private code memories per store when debugging is enabled.

This will allow patching code to implem

Debug: create private code memories per store when debugging is enabled. (#12051)

* Debug: create private code memories per store when debugging is enabled.

This will allow patching code to implement e.g. breakpoints. (That is,
for now the copies are redundant, but soon they will not be.)

This change follows the discussion [here] and offline to define a few
types that better encapsulate the distinction we want to enforce.
Basically, there is almost never a bare `CodeMemory`; they are always
wrapped in an `EngineCode` or `StoreCode`, the latter being a per-store
instance of the former. Accessors are moved to the relevant place so
that, for example, one cannot get a pointer to a Wasm function's body
without being in the context of a `Store` where the containing module
has been registered. The registry then returns a `ModuleWithCode` that
boxes up a `Module` reference and `StoreCode` together for cases where
we need both the metadata from the module and the raw code to derive
something.

The only case where we return raw code pointers to the `EngineCode`
directly have to do with Wasm-to-array trampolines: in some cases, e.g.
`InstancePre` pre-creating data structures with references to host
functions, it breaks our expected performance characteristics to make
the function pointers store-specific. This is fine as long as the
Wasm-to-array trampolines never bake in direct calls to Wasm functions;
the strong invariant is that Wasm functions never execute from
`EngineCode` directly. Some parts of the component runtime would also
have to be substantially refactored if we wanted to do away with this
exception.

The per-`Store` module registry is substantially refactored in this PR.
I got rid of the modules-without-code distinction (the case where a
module only has trampolines and no defined functions still works fine),
and organized the BTreeMaps to key on start address rather than end
address, which I find a little more intuitive (one then queries with the
dual to the range -- 0-up-to-PC and last entry found).

[here]: https://github.com/bytecodealliance/wasmtime/pull/12051#pullrequestreview-3493711812

* Review feedback: do not assume a reasonable code alignment; error when it cannot be known

* Review feedback: fail properly in profiler when we are cloning code

* Fix guest-profiler C API.

* Review feedback: make private-code representation impossible in non-debugging-support builds.

* Add TODO comment referencing issue for cloning only .text.

* clang-format

* Review feedback: add back Component::image_range.

* Review feedback: error on registering profiling metadata when debug is enabled.

* rustfmt

* Remove early bail on profiling-data registration when debugging is enabled: this always happens so we cannot error out.

show more ...

Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)

* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.

This PR impl

Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)

* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.

This PR implements ideas from the [recent RFC] to serve as the basis
for Wasm (guest) debugging: it adds a stackslot to each function
translated from Wasm, stores to replicate Wasm VM state in the
stackslot as the program runs, and metadata to describe the format of
that state and allow reading it out at runtime.

As an initial user of this state, this PR adds a basic "stack view"
API that, from host code that has been called from Wasm, can examine
Wasm frames currently on the stack and read out all of their locals
and stack slots.

Note in particular that this PR does not include breakpoints,
watchpoints, stepped execution, or any sort of user interface for any
of this; it is only a foundation.

This PR still has a few unsatisfying bits that I intend to address:

- The "stack view" performs some O(n) work when the view is initially
taken, computing some internal data per frame. This is forced by the
current design of `Backtrace`, which takes a closure and walks that
closure over stack frames eagerly (rather than work as an
iterator). It's got some impressive iterator-chain stuff going on
internally, so refactoring it to the latter approach might not
be *too* bad, but I haven't tackled it yet.

A O(1) stack view, that is, one that does work only for frames as
the host API is used to walk up the stack, is desirable because some
use-cases may want to quickly examine e.g. only the deepest
frame (say, running with a breakpoint condition that needs to read a
particular local's value after each step).

- It includes a new `Config::compiler_force_inlining()` option that is
used only for testing that we get the correct frames after
inlining. I couldn't get the existing flags to work on a Wasmtime
config level and suspect there may be an existing bug there; I will
try to split out a fix for it.

This PR renames the existing `debug` option to `native_debug`, to
distinguish it from the new approach.

[recent RFC]: https://github.com/bytecodealliance/rfcs/pull/44

* Update to new APIs on Cranelift side.

* Test update.

* Adjust objdump printing of InstPos on frame progpoints; and adjust progpoint collapsing.

* Convert to iterator form.

* Fix path in native-debug tests (debug -> native_debug rename).

* Enforce that `debug_instrumentation` can only be enabled when feature is enabled.

* Add missing assert.

* Use builtin knob for forcing intra-module inlining instead.

* Review feedback:

- Make StackView own the current frame rather than handing it out. This
prevents the current frame (`FrameView`) from walking away and hiding
somewhere it shouldn't, to be used unsoundly later.
- Assert no-GC during stack walk.

* Merge debug-instrumentation hooks on FuncEnvironment into before/after hooks.

* Review feedback: avoid downcasting funcs twice.

* Add debug feature to `wasmtime` crate's defaults.

* Review feedback: u32s for local and stack indices in debug host API.

* Use *const u8 as stack pointers and `with_exposed_provenance` in debug API.

* Remove some `srcloc` plumbing in Wasm translator.

* Rename native-debug back to debug, and make the new thing "guest debugging".

* rustfmt in debugging test.

* fix disas test after guest-debug CLI option rename.

* Review feedback: no separate debug-instrumentation hooks on FuncEnvironment.

* Review feedback: update doc comment on `Config::guest_debug`.

* Review feedback: rename `generate_debuginfo` to `debug_native` in tunables.

* Review feedback: miscellaneous comments.

* Review comment: fix wording in safety conditions.

* revert wasi-common submodule update

* Properly root values in debug frame slots.

Fixes #11841.

* Fix non-`debug`-feature build.

* Review feedback: naming.

* Ignore tests that compile modules in miri.

show more ...

Refactor the representation of `Func` (#10897)

* Refactor the representation of `Func`

This commit rewrites the internals of `wasmtime::Func`. The `Stored`
type is no longer used meaning that it's

Refactor the representation of `Func` (#10897)

* Refactor the representation of `Func`

This commit rewrites the internals of `wasmtime::Func`. The `Stored`
type is no longer used meaning that it's now free to create a
`wasmtime::Func` at any time. It is effectively a store-tagged
`NonNull<VMFuncRef>`. This required a few internal changes to how
functions are passed around:

* Previously the insertion of a `wasm_call`-less `VMFuncRef` was
deferred until the raw pointer was loaded. Now the insertion happens
immediately as soon as the function is placed within a store. This is
done to ensure that a `Func` corresponds to one exact `VMFuncRef` and
that's it, and lazily filled in versions within the store are still
lazily filled in but they're more eagerly allocated. This isn't
expected to have much of an impact perf-wise since all these lazily
allocated functions were already almost guaranteed to get lazily
allocated anyway.

* Filling in "holes" in `VMFuncRef`, notably the `wasm_call` field, no
longer happens lazily when the `VMFuncRef` is demanded. Instead during
instantiation a pass is made to fill in holes with the new module
being instantiated (after registration). Additionally when a
lazily-allocated `VMFuncRef` is created the module registry is checked
immediately. This means that all store-local `VMFuncRef` values are
either filled in immediately or filled in during instantiation. This
notably means that the previous logic in `Func::vmimport` is now
"just" an `.unwrap()` with a lot of comments saying why the unwrap
shouldn't panic.

* To implement this commit a previous optimization for the `Func` API was
removed as well, namely `Func::call` will become slower after this
commit. The `Func::call` API is a dynamically-typed API which requires
run-time type-checking of arguments. Previously a `FuncType` was loaded
into a cache once-per-`Func` which helped amortize the cost of using
`Func::call` repeatedly. Now, though, there's no natural place to put
such a cache since `Func` no longer has dedicated storage within a
`Store`. Historically this optimization was added for the C API before
the `*_call_unchecked` APIs existed, but nowadays the `*_call_unchecked`
APIs should suffice for performance-critical applications where needed.
In the future it might also be possible to have a hash map in the
`Store` of a `VMSharedTypeIndex` to `FuncType` which is lazily populated
based on calls to `Func::call`, but that feels a bit overkill nowadays
for a possibly rarely-used map.

* The no-longer-necessary `RootedHostFunc` type is now gone as its
unsafety and various contracts are subsumed by other preexisting
`unsafe` blocks.

* The specific drop order between `StoreOpaque::store_data` and
`StoreOpaque::rooted_host_funcs` is removed. The `rooted_host_funcs`
field now lives in the `func_refs` field and the `FuncKind` type,
where the destructors came from before, is no more.

* The `func_refs` field has grown storage locations for a variety of
"keep this thing alive as long as the store" related to functions and
such.

Closes #10868

* Remove mutability from locations that no longer need it

* Update crates/wasmtime/src/runtime/func.rs

Co-authored-by: Nick Fitzgerald <[email protected]>

* Update crates/wasmtime/src/runtime/store/func_refs.rs

Co-authored-by: Nick Fitzgerald <[email protected]>

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...

Reuse Wasm linear memories code for GC heaps (#10503)

* Reuse code for Wasm linear memories for GC heaps

Instead of bespoke code paths and structures for Wasm GC, this commit makes it
so that we no

Reuse Wasm linear memories code for GC heaps (#10503)

* Reuse code for Wasm linear memories for GC heaps

Instead of bespoke code paths and structures for Wasm GC, this commit makes it
so that we now reuse VM structures like `VMMemoryDefinition` and bounds-checking
logic. Notably, we also reuse all the associated bounds-checking optimizations
and, when possible, virtual-memory techniques to completely elide them.

Furthermore, this commit adds support for growing GC heaps, reusing the
machinery for growing memories, and makes it so that GC heaps always start out
empty. This allows us to properly delay allocating the GC heap's storage until a
GC object is actually allocated.

Fixes #9350

* fix c api compilation

* use assert_contains

* remove no-longer-necessary extra memory config from limiter tests

* Helper for retry-after-maybe-async-gc in libcalls

* Clean up some comments

* fix wasmtime-fuzzing and no-gc compilation

* fix examples

* fix no-gc+compiler build

* fix build without pooling allocator

* fix +cranelift +gc-drc -gc-null builds

* fix table hash key stability test

* fix oracle usage of `ExternRef::new`

* fix +gc -gc-null -gc-drc build

* fix wasmtime-fuzzing

* make `StorePtr` wrap a `NonNull`

* Fix some doc tests

* Remove some unnecessary retry helpers now that `FooRef::new` will auto-gc

* fix things after rebase

* Reorganize collection/growth methods for GC heap

* rename BoundsCheck variants

* fix cfg'ing of gc only code

* Fix doc tests

* fix one more gc cfg

* disable GC heap OOM test on non-64-bit targets

show more ...

Enable warnings if `gc` is disabled (#10149)

* Enable warnings if `gc` is disabled

Continuation of work in #10131. This additionally handles turning off
`gc-null` and `gc-drc` and the various combi

Enable warnings if `gc` is disabled (#10149)

* Enable warnings if `gc` is disabled

Continuation of work in #10131. This additionally handles turning off
`gc-null` and `gc-drc` and the various combinations within.

* Fix some more warnings

* Fix a feature combo build

show more ...

Enable warnings if `coredump` is disabled (#10135)

Continuation of work in #10131

pulley: Get strings.wast test passing (#9801)

* pulley: Get `strings.wast` test passing

Needed the `imul` CLIF instruction to get implemented so 32/64-bit
multiplication have now been added.

cc #

pulley: Get strings.wast test passing (#9801)

* pulley: Get `strings.wast` test passing

Needed the `imul` CLIF instruction to get implemented so 32/64-bit
multiplication have now been added.

cc #9783

* Flag test as now passing

show more ...

Test Pulley on CI on 32-bit architectures (#9745)

This commit extends our CI for i686 and armv7 to test the Pulley
backend, namely the full `*.wast` test suite as well as the `wasmtime`
crate itself

Test Pulley on CI on 32-bit architectures (#9745)

This commit extends our CI for i686 and armv7 to test the Pulley
backend, namely the full `*.wast` test suite as well as the `wasmtime`
crate itself. Note that many `*.wast` tests are still expected to fail
at this time.

This involved fixing a number of 32-vs-64 bit issues throughout the test
suite in various location in this commit.

show more ...

Support executing Pulley in Wasmtime (#9744)

* Support executing Pulley in Wasmtime

This commit is the initial implementation of executing the Pulley
interpreter from the `wasmtime` crate. This gi

Support executing Pulley in Wasmtime (#9744)

* Support executing Pulley in Wasmtime

This commit is the initial implementation of executing the Pulley
interpreter from the `wasmtime` crate. This gives access to all of the
`wasmtime` crate's runtime APIs backed by execution of bytecode in
Pulley. This builds on the previous PRs I've been making for support in
Pulley to culminate in testing on CI in this PR. This PR handles some
final tidbits related to producing a runnable image that can be
interpreted by the `wasmtime` crate such as:

* Pulley compilation artifacts are no longer marked as natively
executable, just read-only.
* Pulley compilation artifacts include wasm-to-array trampolines like
normal platforms (removes a pulley special-case).
* Dispatch of host calls from Pulley to the Wasmtime runtime are
implemented.
* Pulley's list of panicking wasm features is slimmed down as most are
covered by "this lowering isn't supported" errors.
* Execution of wasm code now has an `if` to see whether Pulley is
enabled within a `Store` or not.
* Traps and basic "unwinding" of the pulley stack are implemented (e.g.
a "pulley version" of `setjmp` and `longjmp`, sort of)
* Halting the interpreter has been refactored to help shrink the size of
`ControlFlow<Done>` and handle metadata with each done state.

Some minor refactorings are also included here and there along with a
few fixes here and there necessary to get tests passing.

The next major part of this commit is updates to our `wast` test suite
and executing all `*.wast` files. Pulley is now executed by default for
all files as a new execution engine. This means that all platforms in CI
will start executing Pulley tests. At this time almost all tests are
flagged as "expected to fail" but there are a small handful of
allow-listed tests which are expected to pass. This exact list will
change over time as CLIF lowerings are implemented and the interpreter
is extended.

Follow-up PRs will extend the testing strategy further such as:

* Extending `#[wasmtime_test]` to include Pulley in addition to Winch.
* Getting testing set up on CI for 32-bit platforms.

prtest:full

* Fix pulley fuzz build

* Fix clippy lints

* Shuffle around some `#[cfg]`'d code

* Remove unused imports

* Update feature sets testing MIRI

Enable pulley for wasmtime/wasmtime-cli and also enable all features for
wasmtime-environ

* Round up pulley's page size to 64k

* Skip pulley tests on s390x for now

* Add a safety rail for matching a pulley target to the host

* Fix more pulley tests on s390x

* Review comments

* Fix fuzz build

show more ...

Add a `signals-based-traps` Cargo compile-time feature (#9614)

* Gate signal handlers behind a new Cargo feature

This commit adds a new on-by-default Cargo feature to the `wasmtime`
crate named `si

Add a `signals-based-traps` Cargo compile-time feature (#9614)

* Gate signal handlers behind a new Cargo feature

This commit adds a new on-by-default Cargo feature to the `wasmtime`
crate named `signals-based-traps`. This is modeled after the
`Config::signals_based_traps` configuration at runtime and can be used
to statically disable the use of signal handlers in Wasmtime. This
notably reduces the number of platform dependencies that Wasmtime has
and provides a mode of avoiding relying on signals altogether.

This introduces a new `MallocMemory` which is a linear memory backed by
the system allocator. This new type of memory is enabled when virtual
memory guards are disabled and signals-based-traps are disabled. This
means that this new type of memory will be candidate for fuzzing for
example.

prtest:full

* Fix rebase conflict

* Refactor `MmapVec` documentation and representation

* Remove no-longer-needed `Arc`
* Document it may be backed by `Vec<u8>`

show more ...

Remove the `wasmtime::runtime::vm::ModuleInfo[Lookup]` traits (#9286)

* Remove the `wasmtime::runtime::vm::ModuleInfo` trait

This harkens back to the `wasmtime` vs `wasmtime-runtime` crate split. W

Remove the `wasmtime::runtime::vm::ModuleInfo[Lookup]` traits (#9286)

* Remove the `wasmtime::runtime::vm::ModuleInfo` trait

This harkens back to the `wasmtime` vs `wasmtime-runtime` crate split. We can
simply use `wasmtime::Module` these days.

* Rename `wasmtime::runtime::vm::ModuleInfoLookup::lookup` to `lookup_module_by_pc`

This will make removing `ModuleInfoLookup` easier in subsequent commits.

* Remove the `ModuleInfoLookup` trait

This harkens back to the `wasmtime` vs `wasmtime-runtime` crate split. We can
simply use the `ModuleRegistry` directly now.

* cargo fmt

show more ...

wasmtime: Remove GET_WASM_TRAP indirection (#8949)

In the past, the wasmtime-runtime crate couldn't directly call
`get_wasm_trap` because the registry of loaded modules was in the
wasmtime crate, so

wasmtime: Remove GET_WASM_TRAP indirection (#8949)

In the past, the wasmtime-runtime crate couldn't directly call
`get_wasm_trap` because the registry of loaded modules was in the
wasmtime crate, so it called through a global function pointer
registered with `init_traps` instead.

Since the two crates were merged in #8501, we no longer need this
indirection.

While I'm here, I've also split the former `get_wasm_trap` function into
two parts: `lookup_code` finds a loaded module that had been previously
registered with `register_code`, and the `lookup_trap_code` step is now
done by a helper on `CodeMemory`. This makes the module registry more
broadly useful.

I also simplified the code lookup step in two ways:
- I removed a redundant check from the code lookup. `BTreeMap::range`
will only return entries where `end >= pc`, so the `end < pc`
condition is always false.
- I used checked_sub instead of writing both the comparison and
subtraction explicitly.

show more ...

Remove the `ModuleRuntimeInfo` trait (#8778)

Replace it with an `enum` of the two possibilities that it can be. This
removes the need to have a trait dispatch indirection in the `vm`
module. Previou

Remove the `ModuleRuntimeInfo` trait (#8778)

Replace it with an `enum` of the two possibilities that it can be. This
removes the need to have a trait dispatch indirection in the `vm`
module. Previously this was required as `wasmtime-runtime` was a
separate crate, but now it's no longer required.

show more ...

Remove the native ABI calling convention from Wasmtime (#8629)

* Remove the native ABI calling convention from Wasmtime

This commit proposes removing the "native abi" calling convention used
in Was

Remove the native ABI calling convention from Wasmtime (#8629)

* Remove the native ABI calling convention from Wasmtime

This commit proposes removing the "native abi" calling convention used
in Wasmtime. For background this ABI dates back to the origins of
Wasmtime. Originally Wasmtime only had `Func::call` and eventually I
added `TypedFunc` with `TypedFunc::call` and `Func::wrap` for a faster
path. At the time given the state of trampolines it was easiest to call
WebAssembly code directly without any trampolines using the native ABI
that wasm used at the time. This is the original source of the native
ABI and it's persisted over time under the assumption that it's faster
than the array ABI due to keeping arguments in registers rather than
spilling them to the stack.

Over time, however, this design decision of using the native ABI has not
aged well. Trampolines have changed quite a lot in the meantime and it's
no longer possible for the host to call wasm without a trampoline, for
example. Compilations nowadays maintain both native and array
trampolines for wasm functions in addition to host functions. There's a
large split between `Func::new` and `Func::wrap`. Overall, there's quite
a lot of weight that we're pulling for the design decision of using the
native ABI.

Functionally this hasn't ever really been the end of the world.
Trampolines aren't a known issue in terms of performance or code size.
There's no known faster way to invoke WebAssembly from the host (or
vice-versa). One major downside of this design, however, is that
`Func::new` requires Cranelift as a backend to exist. This is due to the
fact that it needs to synthesize various entries in the matrix of ABIs
we have that aren't available at any other time. While this is itself
not the worst of issues it means that the C API cannot be built without
a compiler because the C API does not have access to `Func::wrap`.

Overall I'd like to reevaluate given where Wasmtime is today whether it
makes sense to keep the native ABI trampolines. Sure they're supposed to
be fast, but are they really that much faster than the array-call ABI as
an alternative? This commit is intended to measure this.

This commit removes the native ABI calling convention entirely. For
example `VMFuncRef` is now one pointer smaller. All of `TypedFunc` now
uses `*mut ValRaw` for loads/stores rather than dealing with ABI
business. The benchmarks with this PR are:

* `sync/no-hook/core - host-to-wasm - typed - nop` - 5% faster
* `sync/no-hook/core - host-to-wasm - typed - nop-params-and-results` - 10% slower
* `sync/no-hook/core - wasm-to-host - typed - nop` - no change
* `sync/no-hook/core - wasm-to-host - typed - nop-params-and-results` - 7% faster

These numbers are a bit surprising as I would have suspected no change
in both "nop" benchmarks as well as both being slower in the
params-and-results benchmarks. Regardless it is apparent that this is
not a major change in terms of performance given Wasmtime's current
state. In general my hunch is that there are more expensive sources of
overhead than reads/writes from the stack when dealing with wasm values
(e.g. trap handling, store management, etc).

Overall this commit feels like a large simplification of what we
currently do in `TypedFunc`:

* The number of ABIs that Wasmtime deals with is reduced by one. ABIs
are pretty much always tricky and having fewer moving parts should
help improve the understandability of the system.
* All of the `WasmTy` trait methods and `TypedFunc` infrastructure is
simplified. Traits now work with simple `load`/`store` methods rather
than various other flavors of conversion.
* The multi-return-value handling of the native ABI is all gone now
which gave rise to significant complexity within Wasmtime's Cranelift
translation layer in addition to the `TypedFunc` backing traits.
* This aligns components and core wasm where components always use the
array ABI and now core wasm additionally will always use the array ABI
when communicating with the host.

I'll note that this still leaves a major ABI "complexity" with respect
to native functions do not have a wasm ABI function pointer until
they're "attached" to a `Store` with a `Module`. That's required to
avoid needing Cranelift for creating host functions and that property is
still true today. This is a bit simpler to understand though now that
`Func::new` and `Func::wrap` are treated uniformly rather than one being
special-cased.

* Fix miri unsafety

prtest:full

show more ...

Add support for `#![no_std]` to the `wasmtime` crate (#8533)

* Always fall back to custom platform for Wasmtime

This commit updates Wasmtime's platform support to no longer require an
opt-in `RUSTF

Add support for `#![no_std]` to the `wasmtime` crate (#8533)

* Always fall back to custom platform for Wasmtime

This commit updates Wasmtime's platform support to no longer require an
opt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becoming
officially supported this should provide a better onboarding experience
where the fallback custom platform is used. This will cause linker
errors if the symbols aren't implemented and searching/googling should
lead back to our docs/repo (eventually, hopefully).

* Change Wasmtime's TLS state to a single pointer

This commit updates the management of TLS to rely on just a single
pointer rather than a pair of a pointer and a `bool`. Additionally
management of the TLS state is pushed into platform-specific modules to
enable different means of managing it, namely the "custom" platform now
has a C function required to implement TLS state for Wasmtime.

* Delay conversion to `Instant` in atomic intrinsics

The `Duration` type is available in `no_std` but the `Instant` type is
not. The intention is to only support the `threads` proposal if `std` is
active but to assist with this split push the `Duration` further into
Wasmtime to avoid using a type that can't be mentioned in `no_std`.

* Gate more parts of Wasmtime on the `profiling` feature

Move `serde_json` to an optional dependency and gate the guest profiler
entirely on the `profiling` feature.

* Refactor conversion to `anyhow::Error` in `wasmtime-environ`

Have a dedicated trait for consuming `self` in addition to a
`Result`-friendly trait.

* Gate `gimli` in Wasmtime on `addr2line`

Cut down the dependency list if `addr2line` isn't enabled since then
the dependency is not used. While here additionally lift the version
requirement for `addr2line` up to the workspace level.

* Update `bindgen!` to have `no_std`-compatible output

Pull most types from Wasmtime's `__internal` module as the source of
truth.

* Use an `Option` for `gc_store` instead of `OnceCell`

No need for synchronization here when mutability is already available in
the necessary contexts.

* Enable embedder-defined host feature detection

* Add `#![no_std]` support to the `wasmtime` crate

This commit enables compiling the `runtime`, `gc`, and `component-model`
features of the `wasmtime` crate on targets that do not have `std`. This
tags the crate as `#![no_std]` and then updates everything internally to
import from `core` or `alloc` and adapt for the various idioms. This
ended up requiring some relatively extensive changes, but nothing too
too bad in the grand scheme of things.

* Require `std` for the perfmap profiling agent

prtest:full

* Fix build on wasm

* Fix windows build

* Remove unused import

* Fix Windows/Unix build without `std` feature

* Fix some doc links

* Remove unused import

* Fix build of wasi-common in isolation

* Fix no_std build on macos

* Re-fix build

* Fix standalone build of wasmtime-cli-flags

* Resolve a merge conflict

* Review comments

* Remove unused import

show more ...

Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)

* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate

* Rewrite uses of `wasmtime

Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)

* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate

* Rewrite uses of `wasmtime_runtime` to `crate::runtime::vm`

* Remove dep on `wasmtime-runtime` from `wasmtime-cli`

* Move the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module

* Update labeler for merged crates

* Fix `publish verify`

prtest:full

show more ...

Move `VMSharedTypeIndex` to the `wasmtime-types` crate (#8349)

Previously, `wasmtime_types::EngineOrModuleTypeIndex` had a raw `u32` for its
engine-level-canonicalized variant. This change allows it

Move `VMSharedTypeIndex` to the `wasmtime-types` crate (#8349)

Previously, `wasmtime_types::EngineOrModuleTypeIndex` had a raw `u32` for its
engine-level-canonicalized variant. This change allows it to store a
`VMSharedTypeIndex` directly, giving us some additional static assurance that we
aren't messing up our different index types and lets us remove a ton of
conversions back and forth between raw `u32`s and `VMSharedTypeIndex`.

show more ...

Don't lookup trap codes twice on traps (#8150)

* Don't lookup trap codes twice on traps

Currently whenever a signal or trap is handled in Wasmtime we perform
two lookups of the trap code. One durin

Don't lookup trap codes twice on traps (#8150)

* Don't lookup trap codes twice on traps

Currently whenever a signal or trap is handled in Wasmtime we perform
two lookups of the trap code. One during the trap handling itself to
ensure we can handle the trap, and then a second once the trap is
handled. There's not really any need to do two here, however, as the
result of the first can be carried over to the second.

While I was here refactoring things I also changed how some return
values are encoded, such as `take_jmp_buf_if_trap` now returns a more
self-descriptive enum.

* Fix dead code warning on MIRI

* Update crates/environ/src/trap_encoding.rs

Co-authored-by: bjorn3 <[email protected]>

* Fix min-platform build

---------

Co-authored-by: bjorn3 <[email protected]>

show more ...

Wasmtime: Add a `gc` cargo feature (#7975)

* Wasmtime: Add a `gc` cargo feature

This controls whether support for `ExternRef` and its associated deferred,
reference-counting garbage collector is en

Wasmtime: Add a `gc` cargo feature (#7975)

* Wasmtime: Add a `gc` cargo feature

This controls whether support for `ExternRef` and its associated deferred,
reference-counting garbage collector is enabled at compile time or not. It will
also be used for similarly for Wasmtime's full Wasm GC support as that gets
added.

* Add CI for `gc` Cargo feature

* Cut down on the number of `#[cfg(feature = "gc")]`s outside the implementation of `[VM]ExternRef`

* Fix wasmparser reference types configuration with GC disabled/enabled

* More config fix

* doc cfg

* Make the dummy `VMExternRefActivationsTable` inhabited

* Fix winch tests

* final review bits

* Enable wasmtime's gc cargo feature for the C API

* Enable wasmtime's gc cargo feature from wasmtime-cli-flags

* enable gc cargo feature in a couple other crates

show more ...

Support compilation-only build by adding a `runtime` feature (#7766)

* Add `runtime` feature to `wasmtime` crate

This feature can be disabled to build `wasmtime` only for compilation.
This can be u

Support compilation-only build by adding a `runtime` feature (#7766)

* Add `runtime` feature to `wasmtime` crate

This feature can be disabled to build `wasmtime` only for compilation.
This can be useful when cross-compiling, especially on a target that
can't run wasmtime itself (e.g. `wasm32`).

* prtest:full

* don't round pages without runtime feature

* fix async assertions

* move profiling into runtime

* enable runtime for wasmtime-wasi

* enable runtime for c-api

* fix build_artifacts in non-cache case

* fix miri extensions

* enable runtime for wast

* enable runtime for explorer

* support cranelift all-arch on wasm32

* add doc links for `WeakEngine`

* simplify lib runtime cfgs

* move limits and resources to runtime

* move stack to runtime

* move coredump and debug to runtime

* add runtime to coredump and async features

* add wasm32 build job

* combine engine modules

* single compile mod

* remove allow for macro paths

* add comments

show more ...