<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in stackwalk.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>7e0331c2 - Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs#7e0331c2</link>
        <description>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 &quot;execution version&quot; 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&apos;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/unwinder/src/stackwalk.rs</description>
        <pubDate>Wed, 11 Feb 2026 23:43:29 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>5199b1c9 - wasmtime-unwinder: factor out `visit_frames` inner loop to an iterator. (#11783)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs#5199b1c9</link>
        <description>wasmtime-unwinder: factor out `visit_frames` inner loop to an iterator. (#11783)* wasmtime-unwinder: factor out `visit_frames` inner loop to an iterator.This will be desirable to allow a lazy stack-walk for our guestdebugging API. It provides a `frame_iterator()` function that producesan iterator over frames in one Wasm activation, factoring out the heartof `visit_frames`; `visit_frames` is now a thin wrapper around thisiterator. No functional change expected.* Review feedback: add additional safety conditions on iterator.* Use beta rust for x86_64-macosprtest:full---------Co-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs</description>
        <pubDate>Fri, 03 Oct 2025 19:47:48 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>fa1d6867 - Wasmtime/Cranelift: carry &quot;FP to SP offset&quot; in exception data, and use it in stackwalk. (#11500)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs#fa1d6867</link>
        <description>Wasmtime/Cranelift: carry &quot;FP to SP offset&quot; in exception data, and use it in stackwalk. (#11500)* Wasmtime/Cranelift: carry &quot;FP to SP offset&quot; in exception data, and use it in stackwalk.Currently Wasmtime unwinds stack frames to look for exception handlersby walking frames one-by-one, following the FP chain as usual, andassuming that *these frames are contiguous*: that is, that the SP inany given frame (bottom of that frame) is immediately above the FP ofthe next lower frame, plus the FP/return address pair (e.g. 16 bytes).This allows us to get the SP for any given frame in addition to FP. Weneed SP for two reasons:- To look up dynamic context, to match Wasm tag instances for handlers  against the thrown tag;- To actually set SP when we resume, if we do resume to a handler in  this frame.This logic *almost but not quite* worked: I had forgotten that in ourtail-call ABI, we need to clean up incoming stack args in thecallee (because only the final callee in a parade of tail-callingfunctions that reuse the same stack frame location knows how many argsit has, not the original caller). This implies that there is an&quot;incoming args area&quot; *above* the FP/return address pair. Thus, framesare not necessarily contiguous by the above definition.In #11489 we see a case where a function of signature `(func)`tail-calls one of `(func (param i32 i32 i32 i32 i32))`, which onx86-64 (with four arg registers left for Wasm) is sufficient to createincoming stack args, which then trips up the unwinder, reading a bogusvmctx and segfaulting.The most reasonable solution seems to be to embed the SP-to-FP offsetin the exception metadata itself, so from only the FP (which istotally robust -- we rely on the FP chain for multiple kinds ofstack-walking) we can get the SP, allowing us to read dynamic contextand to reset SP during resume.This PR does just that. Technically, in our ABI, the SP-to-FP offsetis constant for an entire function, but it was simpler in theexception metadata to encode this per callsite instead (there is noother notion of &quot;per-function&quot; data, only &quot;per-callsite&quot;, so it wouldbe a separate binary search).Fixes #11489.prtest:full* Review feedback.

            List of files:
            /wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs</description>
        <pubDate>Thu, 21 Aug 2025 22:40:47 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>2d25f862 - WebAssembly exception-handling support. (#11326)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs#2d25f862</link>
        <description>WebAssembly exception-handling support. (#11326)* WebAssembly exception-handling support.This PR introduces support for the [Wasm exception-handling proposal],which introduces a conventional try/catch mechanism to WebAssembly. ThePR supports modules that use `try_table` to register handlers for alexical scope; and provides `throw` and `throw_ref` that allocate (inthe first case) and throw exception objects.This PR builds on top of the work in #10510 for Cranelift-levelexception support, #10919 for an unwinder, and #11230 for exceptionobjects built on top of GC, in addition a bunch of smaller fix andenabling PRs around those.[Wasm exception-handling proposal]: https://github.com/WebAssembly/exception-handling/prtest:full* Permit UnwindToWasm to have unused fields in Pulley builds (for now).* Resolve miri-caught reborrowing issue.* Ignore exceptions tests in miri for now (Pulley not supported).* Use wasmtime_test on exceptions tests.* Get tests passing on pulley platforms* Add a check to `supports_host` for the generated test and assert  failure also when that is false.* Remove `pulley_unsupported` test as it falls out of `#[wasmtime_test]`* Remove `exceptions_store` helper as it falls out of `#[wasmtime_test]`* Remove miri annotations as they fall out of `#[wasmtime_test]`* Remove dead import* Skip some unsupported tests entirely in `#[wasmtime_test]`If the selected compiler doesn&apos;t support the host at all then there&apos;s noneed to run it. Actually running it could misinterpret `CraneliftNative`as &quot;run with pulley&quot; otherwise, so avoid such false negatives.* Cranelift: dynamic contexts: account for outgoing-args area.---------Co-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs</description>
        <pubDate>Thu, 21 Aug 2025 02:55:44 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>2bac6574 - Update the `log` dependency (#11197)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs#2bac6574</link>
        <description>Update the `log` dependency (#11197)* Update the `log` dependencyThis enables getting warnings about formatting strings in the `log`crate directives which are then additionally fixed here as well.* Update dependency directive in `Cargo.toml`

            List of files:
            /wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs</description>
        <pubDate>Mon, 07 Jul 2025 23:25:45 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>91b600a5 - Enable all lints for the `wasmtime-unwinder` crate (#10960)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs#91b600a5</link>
        <description>Enable all lints for the `wasmtime-unwinder` crate (#10960)This is a small enough crate that&apos;s easy to migrate, so don&apos;t opt-out ofthe defaults.

            List of files:
            /wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs</description>
        <pubDate>Fri, 06 Jun 2025 23:44:45 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>efa236e5 - Cranelift: implement an &quot;unwinder&quot; crate and exception throws in filetests. (#10919)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs#efa236e5</link>
        <description>Cranelift: implement an &quot;unwinder&quot; crate and exception throws in filetests. (#10919)This commit introduces the next major piece of machinery (after thepreviously-landed `try_call` support) that we will eventually use toimplement Wasm exceptions in Wasmtime. In particular, it implements ageneric unwinder as a new crate that supports (i) walking a stackproduced by Cranelift code, (ii) serializing Cranelift exceptionmetadata to compact tables (in a way very similar to address maps inWasmtime, so they will be mappable directly from disk), (iii) usingthese serialized tables to find handlers during a stack-walk, and (iv)jumping to handlers (i.e., actually unwinding). This crate is currentlyused in the filetests runner, and will next be used in Wasmtime.The commit first performs code-motion: it moves stack-walking code fromWasmtime to `cranelift-unwinder`. This itself has no functional effect,but isolates the code that understands contiguous sequences of Craneliftframes (&quot;activations&quot;) from that which is specific to Wasmtime&apos;sactivation delimiters and metadata.It then implements a compact exception-table format. This format usesthe `object` crate&apos;s mechanisms for directly referencing in-memoryarrays of little-endian `u32`s in a way that will allow us to findhandlers when mapping exception metadata directly from an ELF section ina `.cwasm` (for example). The format consists of four sorted `u32`arrays in a way that allows us to look up a callsite first, then searchits sorted array of handler offsets by tags.It next implements the actual unwind control flow: it contains anassembly stub for each supported architecture that transfers control toa PC, SP, and FP value &quot;up the stack&quot;, with payload values placed in thepayload registers we have defined per our exception ABI in Cranelift.Finally, it puts these pieces together in the filetest runner. Note thatthe runtest does a lot &quot;by hand&quot;: we don&apos;t have entry and exittrampolines as we do in Wasmtime, so the filetest contains threefunctions, with the middle one invoking the &quot;throw hostcall&quot; and entryand exit trampolines around it grabbing the appropriate entry/exit FPsand exit PC. The dance to call back to host code is also somewhatdelicate, as we haven&apos;t done this before. The `JITModule`&apos;s linking +relocation support does not seem sufficient to properly define a symbol,so instead we scan for `func_addr` instructions referencing a well-knownname (`__cranelift_throw`) and replace them with `iconst`s with thefunction address at runtime, baking it in. This is somewhat ugly, but itworks. All of these filetest-specific details will be handled much morenicely in the Wasmtime version of this functionality, as we have properabstractions for entry/exit trampolines and hostcalls.

            List of files:
            /wasmtime-44.0.1/crates/unwinder/src/stackwalk.rs</description>
        <pubDate>Thu, 05 Jun 2025 01:39:23 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
</channel>
</rss>
