<?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 throw.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>99ecf728 - Debug: create private code memories per store when debugging is enabled.  (#12051)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/throw.rs#99ecf728</link>
        <description>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&apos;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/vm/throw.rs</description>
        <pubDate>Wed, 03 Dec 2025 01:18:00 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>4e8ab840 - Refine raw `VMContext` helpers (#11670)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/throw.rs#4e8ab840</link>
        <description>Refine raw `VMContext` helpers (#11670)This redefines `Instance::from_vmctx` as a function from`NonNull&lt;VMContext&gt;` to `NonNull&lt;Instance&gt;` to canonicalize the singlelocation that pointer arithmetic is done but otherwise require callersto handle the safety requirements of safe references and such.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/throw.rs</description>
        <pubDate>Wed, 10 Sep 2025 20:07:19 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>789f0374 - Package up exception handler state (#11577)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/throw.rs#789f0374</link>
        <description>Package up exception handler state (#11577)* Package up exception handler stateThis commit is a minor refactoring of the `wasmtime-unwinder` crate touse a `Handler` structure as a &quot;package&quot; for the pc/fp/sp triple that&apos;srequired to resume to an exception handler. Freestanding functions are nowassociated methods/functions of `Handler` such as finding a frame on thestack and resuming to a handler.This doesn&apos;t actually change any behavior, just moving some thingsaround to prepare for a future refactoring.* Fix some CI issues* Fix conditional build

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/throw.rs</description>
        <pubDate>Wed, 03 Sep 2025 19:07:30 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&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/wasmtime/src/runtime/vm/throw.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/wasmtime/src/runtime/vm/throw.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/wasmtime/src/runtime/vm/throw.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/wasmtime/src/runtime/vm/throw.rs</description>
        <pubDate>Thu, 21 Aug 2025 02:55:44 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
</channel>
</rss>
