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 #1

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 ability
to keep a handle to a stack frame as long as execution is frozen, and
keep multiple of these handles around, alongside the `Store`, without
any handle directly holding a borrow of the store.

The frame handles work by means of an "execution version" scheme: the
idea is that whenever any execution resumes in a given store, all
handles to existing frames could be invalidated, but if no such
execution occurs, all handles should still be valid. A tuple of
(globally unique for process lifetime) store ID, and execution version
within that store, should be sufficient to uniquely identify any
frozen-stack period during execution. This accomplishes cheap handle
invalidation without the need to track existing handles.

This PR also implements a cache of parsed frame-table data. Previously
this was lazily parsed by the cursor as it walked up a stack, but with
multiple handles hanging around, and with handles meant to be cheap to
hold and clone, and with handles being invalidated eagerly, it makes
much more sense to persist this parsed metadata at the `Store` level.
(It cannot persist at the `Engine` level because PCs are local per
store.)

* 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).

show more ...

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 sta

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 guest
debugging API. It provides a `frame_iterator()` function that produces
an iterator over frames in one Wasm activation, factoring out the heart
of `visit_frames`; `visit_frames` is now a thin wrapper around this
iterator. No functional change expected.

* Review feedback: add additional safety conditions on iterator.

* Use beta rust for x86_64-macos

prtest:full

---------

Co-authored-by: Alex Crichton <[email protected]>

show more ...

Wasmtime/Cranelift: carry "FP to SP offset" in exception data, and use it in stackwalk. (#11500)

* Wasmtime/Cranelift: carry "FP to SP offset" in exception data, and use it in stackwalk.

Currently

Wasmtime/Cranelift: carry "FP to SP offset" in exception data, and use it in stackwalk. (#11500)

* Wasmtime/Cranelift: carry "FP to SP offset" in exception data, and use it in stackwalk.

Currently Wasmtime unwinds stack frames to look for exception handlers
by walking frames one-by-one, following the FP chain as usual, and
assuming that *these frames are contiguous*: that is, that the SP in
any given frame (bottom of that frame) is immediately above the FP of
the 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. We
need 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 our
tail-call ABI, we need to clean up incoming stack args in the
callee (because only the final callee in a parade of tail-calling
functions that reuse the same stack frame location knows how many args
it has, not the original caller). This implies that there is an
"incoming args area" *above* the FP/return address pair. Thus, frames
are 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 on
x86-64 (with four arg registers left for Wasm) is sufficient to create
incoming stack args, which then trips up the unwinder, reading a bogus
vmctx and segfaulting.

The most reasonable solution seems to be to embed the SP-to-FP offset
in the exception metadata itself, so from only the FP (which is
totally robust -- we rely on the FP chain for multiple kinds of
stack-walking) we can get the SP, allowing us to read dynamic context
and to reset SP during resume.

This PR does just that. Technically, in our ABI, the SP-to-FP offset
is constant for an entire function, but it was simpler in the
exception metadata to encode this per callsite instead (there is no
other notion of "per-function" data, only "per-callsite", so it would
be a separate binary search).

Fixes #11489.

prtest:full

* Review feedback.

show more ...

WebAssembly exception-handling support. (#11326)

* WebAssembly exception-handling support.

This PR introduces support for the [Wasm exception-handling proposal],
which introduces a conventional try

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. The
PR supports modules that use `try_table` to register handlers for a
lexical scope; and provides `throw` and `throw_ref` that allocate (in
the first case) and throw exception objects.

This PR builds on top of the work in #10510 for Cranelift-level
exception support, #10919 for an unwinder, and #11230 for exception
objects built on top of GC, in addition a bunch of smaller fix and
enabling 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't support the host at all then there's no
need to run it. Actually running it could misinterpret `CraneliftNative`
as "run with pulley" otherwise, so avoid such false negatives.

* Cranelift: dynamic contexts: account for outgoing-args area.

---------

Co-authored-by: Alex Crichton <[email protected]>

show more ...

Update the `log` dependency (#11197)

* Update the `log` dependency

This enables getting warnings about formatting strings in the `log`
crate directives which are then additionally fixed here as wel

Update the `log` dependency (#11197)

* Update the `log` dependency

This 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`

show more ...

Enable all lints for the `wasmtime-unwinder` crate (#10960)

This is a small enough crate that's easy to migrate, so don't opt-out of
the defaults.

Cranelift: implement an "unwinder" crate and exception throws in filetests. (#10919)

This commit introduces the next major piece of machinery (after the
previously-landed `try_call` support) that we

Cranelift: implement an "unwinder" crate and exception throws in filetests. (#10919)

This commit introduces the next major piece of machinery (after the
previously-landed `try_call` support) that we will eventually use to
implement Wasm exceptions in Wasmtime. In particular, it implements a
generic unwinder as a new crate that supports (i) walking a stack
produced by Cranelift code, (ii) serializing Cranelift exception
metadata to compact tables (in a way very similar to address maps in
Wasmtime, so they will be mappable directly from disk), (iii) using
these serialized tables to find handlers during a stack-walk, and (iv)
jumping to handlers (i.e., actually unwinding). This crate is currently
used in the filetests runner, and will next be used in Wasmtime.

The commit first performs code-motion: it moves stack-walking code from
Wasmtime to `cranelift-unwinder`. This itself has no functional effect,
but isolates the code that understands contiguous sequences of Cranelift
frames ("activations") from that which is specific to Wasmtime's
activation delimiters and metadata.

It then implements a compact exception-table format. This format uses
the `object` crate's mechanisms for directly referencing in-memory
arrays of little-endian `u32`s in a way that will allow us to find
handlers when mapping exception metadata directly from an ELF section in
a `.cwasm` (for example). The format consists of four sorted `u32`
arrays in a way that allows us to look up a callsite first, then search
its sorted array of handler offsets by tags.

It next implements the actual unwind control flow: it contains an
assembly stub for each supported architecture that transfers control to
a PC, SP, and FP value "up the stack", with payload values placed in the
payload registers we have defined per our exception ABI in Cranelift.

Finally, it puts these pieces together in the filetest runner. Note that
the runtest does a lot "by hand": we don't have entry and exit
trampolines as we do in Wasmtime, so the filetest contains three
functions, with the middle one invoking the "throw hostcall" and entry
and exit trampolines around it grabbing the appropriate entry/exit FPs
and exit PC. The dance to call back to host code is also somewhat
delicate, as we haven't done this before. The `JITModule`'s linking +
relocation support does not seem sufficient to properly define a symbol,
so instead we scan for `func_addr` instructions referencing a well-known
name (`__cranelift_throw`) and replace them with `iconst`s with the
function address at runtime, baking it in. This is somewhat ugly, but it
works. All of these filetest-specific details will be handled much more
nicely in the Wasmtime version of this functionality, as we have proper
abstractions for entry/exit trampolines and hostcalls.

show more ...