en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs#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/crates/cranelift/src/compiled_function.rs Tue, 31 Mar 2026 18:00:46 +0000 Chris Fallin <chris@cfallin.org> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs#17fbd3c6 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/cranelift/src/compiled_function.rs Fri, 12 Dec 2025 20:02:54 +0000 Chris Fallin <chris@cfallin.org> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs#02155232 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 basisfor Wasm (guest) debugging: it adds a stackslot to each functiontranslated from Wasm, stores to replicate Wasm VM state in thestackslot as the program runs, and metadata to describe the format ofthat 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 examineWasm frames currently on the stack and read out all of their localsand stack slots.Note in particular that this PR does not include breakpoints,watchpoints, stepped execution, or any sort of user interface for anyof 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`, todistinguish 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. List of files: /wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs Wed, 15 Oct 2025 00:03:52 +0000 Chris Fallin <chris@cfallin.org> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs#90ac295e Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs Mon, 19 May 2025 16:40:55 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs#7be834f6 Enable some Clippy conversion lints for `wasmtime-cranelift` (#9536)Similar to how `wasmtime::runtime` has a few off-by-default lints turnedon for it do the same for the compilation phase of `wasmtime-cranelift`.This is intended to help weed out lossy `as` casts and instead steerusers to `from` or `try_from` conversions. List of files: /wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs Fri, 01 Nov 2024 17:20:04 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs#d38d387a Fix rustdoc warnings on Nightly (#8258)* Fix rustdoc warnings on NightlyI noticed during a failed doc build of another PR we've got a number ofwarnings being emitted, so resolve all those here.* Fix more warnings* Fix rebase conflicts List of files: /wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs Thu, 28 Mar 2024 19:19:22 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs#355990b4 Exit through Cranelift-generated trampolines for builtins (#8152)* Exit through Cranelift-generated trampolines for builtinsThis commit changes how builtin functions in Wasmtime (think`memory.grow`) are implemented. These functions are required to exitthrough some manner of trampoline to handle runtime requirements forbacktracing right now. Currently this is done via inline assembly foreach architecture (or external assembly for s390x). This is a bitunfortunate as it's a lot of hand-coding and making sure everything isright, and it's not easy to update as it's multiple platforms to update.The change in this commit is to instead use Cranelift-generatedtrampolines for this purpose instead. The path for invoking a builtinfunction now looks like:* Wasm code calls a statically known symbol for each builtin.* The statically known symbol will perform exit trampoline duties (e.g. pc/fp/etc) and then load a function pointer to the host implementation.* The host implementation is invoked and then proceeds as usual.The main new piece for this PR is that all wasm modules and functionsare compiled in parallel but an output of this compilation phase is whatbuiltin functions are required. All builtin functions are then unionedtogether into one set and then anything required is generated justafterwards. That means that only one builtin-trampoline per-module isgenerated per-builtin.This work is inspired by #8135 and my own personal desire to have asmuch about our ABI details flowing through Cranelift as we can. This intheory makes it more flexible to deal with future improvements to ourABI.prtest:full* Fix some build issues* Update winch test expectations* Update Winch to use new builtin shims.This commit refactors the Winch compiler to use the new trampolines forall Wasmtime builtins created in the previous commits. This required afair bit of refactoring to handle plumbing through a new kind ofrelocation and function call.Winch's `FuncEnv` now contains a `PrimaryMap` from `UserExternalNameRef`to `UserExternalName`. This is because there's now more than one kind ofname than just wasm function relocations, so the raw index space of`UserExternalNameRef` is no longer applicable. This required threading`FuncEnv` to more locations along with some refactorings to ensure thatlifetimes work out ok.The `CompiledFunction` no longer stores a trait object of how to mapname refs to names and now directly has a `Primarymap`. This also meansthat Winch's return value from its `TargetIsa` is a `CompiledFunction`as opposed to the previous just-a-`MachBuffer` so it can also package upall the relocation information. This ends up having `winch-codegen`depend on `wasmtime-cranelift-shared` as a new dependency.* Review feedback List of files: /wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs Fri, 22 Mar 2024 20:34:26 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs#b545cc50 Remove the wasmtime-cranelift-shared crate (#8222)The wasmtime-cranelift-shared crate is not as useful as it once was, asit's no longer possible to build wasmtime with only winch; winch usesthe trampolines generated by cranelift now. List of files: /wasmtime-44.0.1/crates/cranelift/src/compiled_function.rs Fri, 22 Mar 2024 19:29:38 +0000 Trevor Elliott <telliott@fastly.com>