Changes in debug.rs

4c7c01dc - Debugging: add debugger support for `wasmtime serve`. (#12859)

Wed, 01 Apr 2026 01:33:44 +0000

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/crates/wasmtime/src/runtime/debug.rs

9500c417 - Several fixes to debugging infrastructure: component vs. module PCs and gdbstub wasm module names. (#12901)

Tue, 31 Mar 2026 18:00:46 +0000

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/crates/wasmtime/src/runtime/debug.rs

439de7fb - Handle OOM in the rest of Wasmtime's non-component, -async, -compilation APIs (#12858)

Mon, 30 Mar 2026 18:35:31 +0000

Handle OOM in the rest of Wasmtime's non-component, -async, -compilation APIs (#12858)* Handle OOM in more places in the public APIA bunch of random places:* Add: `Trap::try_new` to handle OOM while creating traps* Use: `TryVec` inside `Func::call_impl_do_call` and `wasm_val_raw_storage` to hold the args and rets* Add: `Instance::try_exports` for iterating over an instance's exports while handling OOM* `Linker:try_get`, like `Linker::get` but handling OOM* `Linker:try_get_by_import`, like `Linker::get_by_import` but handling OOM* Use `try_new` to box things in `SharedMemory::new`* Use `TryVec` instead of `Vec` in our dynamic tables* Add OOM tests for most of Wasmtime's public APIExcludes component-, async-, and compilation-related APIs.* address review feedback* fix test compilation* fix c-api List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

ab78bd82 - fix: correct various typos (#12807)

Sun, 22 Mar 2026 18:10:20 +0000

fix: correct various typos (#12807)Signed-off-by: Ho Kim List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

97361cce - Debugging: allow breakpoints to be set at "function start" by slipping forward to first opcode. (#12791)

Thu, 19 Mar 2026 01:43:22 +0000

Debugging: allow breakpoints to be set at "function start" by slipping forward to first opcode. (#12791)LLDB, when instructed to `break main`, looks at the DWARF metadata for`main` and finds its PC range, then sets a breakpoint at the firstPC. This is reasonable behavior for native ISAs! That PC better be areal instruction!On Wasm, however, (i) toolchains typically emit the PC range as*including* the *locals count*, a leb128 value that precedes the firstopcode and any types of locals; (ii) our gdbstub component thatbridges LLDB to our debug APIs (#12771) only supports *exact* PCs forbreakpoints, so when presented with a PC that does not actually pointto an opcode, setting the breakpoint is effectively a no-op. Therewill always be a difference of at least 1 byte between thestart-of-function offset and first-opcode offset (for a leb128 of `0`for no locals), so a breakpoint "on" a function will never work.I initially prototyped a fix that adds a sequence point at the startof every function (which, again, is *guaranteed* to be distinct fromthe first opcode), and the branch is [here], but I didn't like thedeveloper experience: this meant that when a breakpoint at a functionstart fired, LLDB had a weird interstitial state where no line-numberapplied.The behavior that would be closer in line with "native" debugexpectations is that we add a bit of fuzzy-ish matching: setting abreakpoint at function start should break at the first opcode, even ifthat's a few (or many) bytes later. There are two options here:special-case function start, or generally change the semantics of ourbreakpoint API so that "add breakpoint at `pc`" means "add breakpointat next opcode at or after `pc`". I opted for the latter in this PRbecause it's more consistent.The logic is a little subtle because we're effectively defining ann-to-1 mapping with this "snap-to-next" behavior, so we have torefcount each breakpoint (consider setting a breakpoint at functionstart *and* at the first opcode, then deleting them, one at a time). Ibelieve the result is self-consistent, even if a little morecomplicated now. And, importantly, with #12771 on top of this change,it produces the expected behavior for the (very simple!) debug script"`b main`; `continue`".[here]: https://github.com/cfallin/wasmtime/tree/breakpoint-at-func-start List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

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

Wed, 25 Feb 2026 00:01:48 +0000

Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)We currently do a store-wide state-change on all registered moduleswhen the "single stepping" flag changes, patching in or out allbreakpoints. However, this design didn't account for modulesregistered with the store *after* single-stepping is enabled (and newmodules may be registered any time an instantiation occurs). Inparticular this is problematic when a debugger, e.g., sets thesingle-step flag right at the beginning of execution of a "host mainfunction" 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 onlyplace where modules are added to the `LoadedCode`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

28425527 - Debugging: avoid re-patching code on single-step update when state doesn't change. (#12638)

Mon, 23 Feb 2026 22:53:13 +0000

Debugging: avoid re-patching code on single-step update when state doesn't change. (#12638)When the setter for the single-step flag is given an `enable` booleanthat matches the existing state (i.e., enabling when already enabled ordisabling when already disabled), we should not loop through andre-patch all breakpoint patch sites. This is an optimization, notrequired for correctness, but a rather obvious optimization to make (andimportant when building higher-level APIs for e.g. a single-step commandthat always set the flag). List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

bc6483b5 - Debugging: add `debug_all_modules()` / `debug_all_instances()` accessors on `Store`. (#12637)

Mon, 23 Feb 2026 22:32:46 +0000

Debugging: add `debug_all_modules()` / `debug_all_instances()` accessors on `Store`. (#12637)* Debugging: add `debug_all_modules()` / `debug_all_instances()` accessors on `Store`.When writing a debugger top-half using Wasmtime's debug APIs, it isessential to be able to list all moules, and all instances, within a`Store`. This PR adds those APIs.The way in which the debug APIs are placed onStore/StoreContextMut/Caller/etc is also refactored to be more uniform.* ignore new test with compilation in miri List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

92f1829e - miri: add guest-debugging, including frame accesses. (#12575)

Thu, 12 Feb 2026 23:59:26 +0000

miri: add guest-debugging, including frame accesses. (#12575)* miri: add guest-debugging, including frame accesses.The fix to `vm_store_context` provenance in `record_unwind`/`unwind`is a little weird to me. I was seeing mut access to the`vm_store_context` via `store.vm_store_context_mut()` in`record_unwind` (before this diff) then access via the previouslysaved raw pointer in the `CallThreadState`, which was registered asinvalid and I believe is indeed invalid. This was only manifestingwhen setting `Config::guest_debug`, even without the frame-handleaccesses added here. I didn't dig into the exact diff in codegen orruntime behavior that caused this but in any case, accessing`vm_store_context` via these two different paths (with one mut)appears to be unsound in any case. The fix here is to set the unwindstate via the raw pointer in `CallThreadState` since that's the onlypath that the subsequent `unwind` has access to.Unrelated but useful: `ci/miri-provenance.test.sh` now accepts`MIRI_RUST_VERSION=+nightly` or whatnot, which is nice for runninglocally (I keep `stable` as my default toolchain).* Revert MIRI_RUST_VERSION in the CI script and add note about `rustup run` instead.* Add a bit more usage of debug API to Pulley provenance test.* Switch to using `Store`-derived `VMStoreContext` where available and re-deriving the raw pointer in `CallThreadState`.prtest:full List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

d9038ed0 - Cranelift/Wasmtime/Pulley/Debugging: use little-endian mode to spill/reload vectors in guest-debugging slot and ABI clobbers. (#12585)

Thu, 12 Feb 2026 23:13:00 +0000

Cranelift/Wasmtime/Pulley/Debugging: use little-endian mode to spill/reload vectors in guest-debugging slot and ABI clobbers. (#12585)* Cranelift/Wasmtime/Pulley/Debugging: use little-endian mode to spill/reload vectors in guest-debugging slot and ABI clobbers.When running Pulley on an s390x (or other big-endian) host, and enablingguest-debugging instrumentation, a very strange confluence of eventsoccurs:- Pulley uses "native endian" of the host by default for loads and stores.- Patchable calls to debug hooks use the `preserve_all` ABI, which spills all registers in the trampoline adapter (callee in this ABI), including vector registers.- Saving vector-typed locals/operand stack values to the debugger state slot also uses vector stores.- All of these stores were thus big-endian on big-endian hosts.- Pulley's bytecode only supports little-endian vector loads/stores.We were thus hitting an assert in Pulley codegen (the Craneliftbackend) when encountering a `VStore` VCode instruction with abig-endian mode.This PR makes two changes that avoid this issue:- The ABI code for Pulley is careful to specify little-endian mode explicitly for any vector load/store.- The debug instrumentation code is refactored to use little-endian explicitly for vector types *only*. - (Why not for all types? Because we GC-root GC ref values, and these need to be provided to the collector as mutable storage cells, so need to be in native endianness.)Test will come as part of #12575 incorporating aPulley-with-guest-debugging test and running on s390x amongst ourplatforms.prtest:full* Review feedback.* Re-bless Cranelift tests (explicit `little` flags on `preserve_all` tests). List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

7e0331c2 - Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)

Wed, 11 Feb 2026 23:43:29 +0000

Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)* Debugging: refactor stack frame cursor into frame handle abstraction.This addresses some of the issues described #12486: we need the abilityto keep a handle to a stack frame as long as execution is frozen, andkeep multiple of these handles around, alongside the `Store`, withoutany handle directly holding a borrow of the store.The frame handles work by means of an "execution version" scheme: theidea is that whenever any execution resumes in a given store, allhandles to existing frames could be invalidated, but if no suchexecution occurs, all handles should still be valid. A tuple of(globally unique for process lifetime) store ID, and execution versionwithin that store, should be sufficient to uniquely identify anyfrozen-stack period during execution. This accomplishes cheap handleinvalidation without the need to track existing handles.This PR also implements a cache of parsed frame-table data. Previouslythis was lazily parsed by the cursor as it walked up a stack, but withmultiple handles hanging around, and with handles meant to be cheap tohold and clone, and with handles being invalidated eagerly, it makesmuch more sense to persist this parsed metadata at the `Store` level.(It cannot persist at the `Engine` level because PCs are local perstore.)* Re-bless disas tests (offsets in VMStoreContext changed).* Handle invalidation tests.* Review comments, and make API return `Result`s rather than panic'ing on stale handles.* Review feedback.* Doc-comment link fix.* Review feedback.* cfg-gate Activation method to `debug` feature only.* Fix unused-import warning in no-debug cfg.* Fix doc link (again, after rename from latest feedback). List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

bc4582c3 - Forbid rustdoc warnings in CI (#12420)

Tue, 27 Jan 2026 03:47:35 +0000

Forbid rustdoc warnings in CI (#12420)* Forbid rustdoc warnings in CIThis commit corrects our handling of rustdoc flags in CI to ensure thatwarnings indeed fire. Additionally this changes our flags to pass`-Dwarnings` to ensure that we have warning-free doc builds when allfeatures are enabled at least.There were quite a lot of preexisting issues to fix, so thisadditionally goes through and fixes all the warnings that cropped up.* Update nightly toolchain againprtest:full* Update another nightly* Fix a warning in generated code List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

af0ae833 - Reduce duplication amongst `debug_*` helpers (#12386)

Wed, 21 Jan 2026 22:10:44 +0000

Reduce duplication amongst `debug_*` helpers (#12386)Deduplicate the check for `guest_debug`, validity checks, and conversionfrom `Export` to `Extern`. No functional change here, just arefactoring. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

2326d655 - Debugging: provide access to private (non-exported) entities. (#12367)

Wed, 21 Jan 2026 17:00:31 +0000

Debugging: provide access to private (non-exported) entities. (#12367)* Debugging: provide access to private (non-exported) entities.A debugger will need to access all entities (globals, tables, memories),even those that are not exported, in order to provide a full debuggingexperience: for example, a developer who has a debugger attached to aWasm component will expect to be able to see data in its memory.Historically we have been very careful in Wasmtime to provide access toWasm instances' entities only as the Wasm type system allows -- that is,only if they are exported. However, debugging is privileged -- in thesame way that a native host debugger has `ptrace` and can vieweverything about the debuggee, we need to provide APIs for seeingthrough the encapsulation boundary.To ensure that this "violation of encapsulation" is scoped only to theextent needed for the legitimate need (debugging), this API isdynamically available only when `guest_debug` is configured true for agiven engine. Otherwise, the accessor returns `None`.I opted not to provide a full introspection API that enumerates all ofthe entities as the debugger should already have access to the debuggeemodule and be able to enumerate the entities. Thus, the API onlyprovides a host-API handle when asking for an entity by index in a giveninstance's index space.* Review feedback.* Fix tests on 32-bit build (where threads and thus shared memory are not supported) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

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

Wed, 07 Jan 2026 17:08:11 +0000

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, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse 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 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

19a0946b - Debug: clarify safety around ActivationBacktrace::new. (#12191)

Mon, 22 Dec 2025 16:43:32 +0000

Debug: clarify safety around ActivationBacktrace::new. (#12191)* Debug: clarify safety around ActivationBacktrace::new.As per [this discussion], we decided that we would handle potentialframe-cursor invalidation unsafety (with a hypothetical futureframe-editing debugger API) by putting `unsafe` on that futurehypothetical API rather than on the cursor construction. With the APIsavailable today on the `Store`, there is no way to invalidate the framecursor while within its lifetime-bounded scope (with lifetime tied tothe `Store` that is passed into the hostcall creating the cursor), sothe API today should be completely safe. This PR makes it so.[this discussion]: https://github.com/bytecodealliance/wasmtime/pull/12176#discussion_r2636431864* store_mut is safe as well. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

88bdf791 - Debugging: add event for epoch yields. (#12194)

Mon, 22 Dec 2025 16:04:28 +0000

Debugging: add event for epoch yields. (#12194)This will almost certainly be needed to implement "Ctrl-C" behavior fora gdbstub server or other user-facing debugger top-half, so the user caninterrupt the debuggee and return control to the debugger. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

23b2fe3f - Debugging: allow frame cursor to visit all activations. (#12176)

Wed, 17 Dec 2025 21:39:11 +0000

Debugging: allow frame cursor to visit all activations. (#12176)* Debugging: allow frame cursor to visit all activations.In the initial design for the `DebugFrameCursor`, I was concernedabout the effects of host async on the stability of visiting earlieractivations (see also the discussion of async combinators in #11896).The basic hypothesized problem was that when Wasm calls host-codecalls Wasm, the sequence of activations on the stack is not evenstable between async polls; so any debugger hook, which is an asyncfunction, should not be allowed to hold a frame cursor across a yieldpoint since it could become invalidated if the next poll stacks up theactivations differently.In further conversations it's become clear that this is not actually apossibility, for the simple reason that the inner re-entrantactivations into the same store take full ownership (mutably reborrow)that store, and that mut reborrow becomes part of the future; so theexact chain of activations will remain in the same sequence whenre-polled. Said another way, it is impossible at any given level ofasync host-code to create *more than one* future that re-enters thesame store and somehow poll those in different orders at differenttimes. The worst that a host-code async combinator can do is drop thefuture that re-enters the store. This drops and invalidates whateverframes a cursor held over a yield might be referencing, but it *also*drops the async invocation of the debugger hook itself, and due tolifetimes the cursor cannot escape that hook, so everything is stillsound.This PR thus updates the `DebugFrameCursor` to visit allactivations. I've generalized the backtrace code a bit to enable this,and built an internal `StoreBacktrace` that is an iterator over allactivations associated with the store.At the `DebugFrameCursor` (public API) level, the two basic choiceswere to present a sentinel for host frame(s) explicitly and make allWasm-specific accessors return `Option`, or skip over hostframes. I opted for the latter, with `move_to_parent()` returning anenum value now that indicates whether it moved to a new activation.A note regarding the *async* component ABI: once debugging is possiblewithin a `run_concurrent` environment, it will again be the case thata single frame cursor should see only one activation, becauseeach (re)-entry into the store becomes a new task, if my understandingis correct. At that time, we should build an API that lets thedebugger see the activation for each task separately. That's a simplermodel ultimately, and it will be nice when we move to it, but as longas we have the sync component ABI with async host code and the abilityto stack activations as we do today, we need to provide the debuggerthis visibility.(Aside: why does the debugger *need* to see more than one activation?In addition to presenting a weird and incoherent view of the world tothe user if we don't, it is also necessary to implement the"next" (step-over) debugger action, because otherwise a call to a hostfunction that re-enters the store may lead to a state with fewer, butcompletely disjoint, stack frames on the "one latest activation" fromwhich it's not possible to reason about whether we've left thecalled-into function yet.)* Review feedback.* cargo fmt. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

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

Fri, 12 Dec 2025 20:02:54 +0000

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 (patchablecalls in #12061 and #12101, private copies of code in #12051, and allthe prior debug event and instrumentation infrastructure) to implementbreakpoints in the guest debugger.These are implemented in the way we have planned in #11964: eachsequence point (location prior to a Wasm opcode) is now a patchable callinstruction, patched out (replaced with NOPs) by default. When patchedin, the breakpoint callsite calls a trampoline with the `patchable` ABIwhich then invokes the `breakpoint` hostcall. That hostcall emits thedebug 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 todo *all* patches in all modules registered in the `Store` when that flagis 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 onmacOS/aarch64 that is consistent with patched-in breakpoint calls stillbeing incorrectly cached after we remove them and republish the code.There is a longstanding issue in #3310 tracking proper icache coherencehandling on aarch64. We implemented this for Linux with the `membarrier`syscall but never did so for macOS. Maybe this is the first point atwhich it matters, because code was always loaded at new addresses (hencedid not have coherence issues because nothing would have been cached)previously.prtest:full* Review feedback: use `next_multiple_of`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs

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

Wed, 03 Dec 2025 01:18:00 +0000

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 fewtypes that better encapsulate the distinction we want to enforce.Basically, there is almost never a bare `CodeMemory`; they are alwayswrapped in an `EngineCode` or `StoreCode`, the latter being a per-storeinstance of the former. Accessors are moved to the relevant place sothat, for example, one cannot get a pointer to a Wasm function's bodywithout being in the context of a `Store` where the containing modulehas been registered. The registry then returns a `ModuleWithCode` thatboxes up a `Module` reference and `StoreCode` together for cases wherewe need both the metadata from the module and the raw code to derivesomething.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 hostfunctions, it breaks our expected performance characteristics to makethe function pointers store-specific. This is fine as long as theWasm-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 alsohave to be substantially refactored if we wanted to do away with thisexception.The per-`Store` module registry is substantially refactored in this PR.I got rid of the modules-without-code distinction (the case where amodule only has trampolines and no defined functions still works fine),and organized the BTreeMaps to key on start address rather than endaddress, which I find a little more intuitive (one then queries with thedual 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. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/debug.rs