en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/#4c7c01dc Debugging: add debugger support for `wasmtime serve`. (#12859)This adopts a simple solution to #12776: it takes the "instance reuse"paradigm to the extreme, instantiating exactly one instance andserializing all requests into that one instance. This allows thedebugger component to operate on one `Store`, setting breakpoint stateand presenting its execution to the attached debugger as a singleprogram execution and minimizing impedance mismatches.This also adds an integration test that runs an existing wasi-httptest component under the debugger. List of files: /wasmtime-44.0.1/src/commands/run.rs/wasmtime-44.0.1/src/commands/serve.rs Wed, 01 Apr 2026 01:00:00 +0000 Chris Fallin <chris@cfallin.org> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/#9500c417 Several fixes to debugging infrastructure: component vs. module PCs and gdbstub wasm module names. (#12901)* Debugging: fix module-relative vs component-relative PCs and unique library names.Two bugfixes for guest debugging with components:1. Convert component-relative source locations to module-relative PCs in the frame table. The guest-debug API presents a core-Wasm view where components are deconstructed into individual modules, so all PCs must be module-relative. This adds a `wasm_module_offset` field to `ModuleTranslation` and `FuncEnvironment`, set during component translation, and subtracts it in `debug_tags()`.2. Give unique names to "library" entries in the gdbstub XML response. LLDB's DynamicLoader deduplicates by name, so using "wasm" for all modules caused only the first to be loaded.* Debugging: add ModulePC and ComponentPC newtypes for Wasm PC offsets.Introduce `ModulePC` (module-relative) and `ComponentPC`(component-relative) newtype wrappers around u32 Wasm bytecodeoffsets. These replace raw u32 values throughout the frame table,breakpoint, and debug systems to prevent confusion between the twooffset spaces.* Debugging: add regression test for component module-relative PCs. List of files: /wasmtime-44.0.1/src/commands/objdump.rs Tue, 31 Mar 2026 18:00:00 +0000 Chris Fallin <chris@cfallin.org> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/#94740588 Migrate the Wasmtime CLI to `wasmtime::error` (#12295)* Migrate wasmtime-cli to `wasmtime::error`* migrate benches to `wasmtime::error` as well* Remove new usage of anyhow that snuck in List of files: /wasmtime-44.0.1/src/commands/explore.rs Fri, 09 Jan 2026 19:00:00 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/src/commands/#cc8d04f4 Remove need for explicit `Config::async_support` knob (#12371)* Refactor component model host function definitionsPush the `async`-ness down one layer.* Remove need for explicit `Config::async_support` knobThis commit is an attempt to step towards reconciling "old async" and"new async" in Wasmtime. The old async style is the original asyncsupport in Wasmtime with `call_async`, `func_wrap_async`, etc, where themain property is that the store is "locked" during an async operation.Put another way, a store can only execute at most one async operation ata time. This is in contrast to "new async" support in Wasmtime with thecomponent-model-async (WASIp3) support, where stores can have more thanone async operation in flight at once.This commit does not fully reconcile these differences, but it doesremove one hurdle along the way: `Config::async_support`. Since thebeginning of Wasmtime this configuration knob has existed to explicitlydemarcate a config/engine/store as "this thing requires `async` stuffinternally." This has started to make less and less sense over timewhere the line between sync and async has become more murky with WASIp3where the two worlds comingle. The goal of this commit is to deprecate`Config::async_support` and make the function not actually do anything.In isolation this can't simply be done, however, because there are manyload-bearing aspects of Wasmtime that rely on this `async_support` knob.For example once epochs + yielding are enabled it's required that allWasm is executed on a fiber lest it hit an epoch and not know how toyield. That means that this commit is not a simple removal of`async_support` but instead a refactoring/rearchitecting of how async isused internally within Wasmtime. The high-level ideas within Wasmtimenow are:* A `Store` has a "requires async" boolean stored within it.* All configuration options which end up requiring async, such as yielding with epochs, turn this boolean on.* Creation of host functions which use async (e.g. `func_wrap_{async,concurrent}`) will also turn this option on.* Synchronous API entrypoints into Wasmtime ensure that this boolean is disabled.* Asynchronous APIs are usable at any time.This means that the concept of an async store vs a sync store is nowgone. All stores are equally capable of executing sync/async, and thechange now is that dynamically some stores will require that async isused with certain configuration. Additionally all panicking conditionsaround `async_support` have been converted to errors instead. Allrelevant APIs already returned an error and things are murky enough nowthat it's not necessarily trivial to get this right at the embedderlevel. In the interest of avoiding panics all detected async mismatchesare now first-class `wasmtime::Error` values.The end result of this commit is that `Config::async_support` is adeprecated `#[doc(hidden)]` function that does nothing. While manyinternal changes happened as well as having new tests for all this sortof behavior this is not expected to have a great impact on externalconsumers. In general a deletion of `async_support(true)` is in theoryall that's required. This is intended to make it easier to think aboutasync/sync/etc in the future with WASIp3 and eventually reconcile`func_wrap_async` and `func_wrap_concurrent` for example. That's leftfor future refactorings however.prtest:full* Review comments* Fix CI failures List of files: /wasmtime-44.0.1/src/commands/wast.rs Fri, 23 Jan 2026 02:00:00 +0000 Alex Crichton <alex@alexcrichton.com>