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 Wasmtim
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
show more ...
Add a `wasmtime objdump` subcommand (#10405)This commit adds an `objdump` subcommand to the `wasmtime` CLI. Like allother subcommands this can be disabled for a more minimal build of theCLI as we
Add a `wasmtime objdump` subcommand (#10405)This commit adds an `objdump` subcommand to the `wasmtime` CLI. Like allother subcommands this can be disabled for a more minimal build of theCLI as well. The purpose of this subcommand is to provide aWasmtime-specific spin on the venerable native `objdump` itself. Notablythis brings Wasmtime-specific knowledge for filtering functions, showingWasmtime metadata, etc.This command is intended to look like `objdump` roughly but also hasconfigurable output with various flags and things that can be printed.For now the main Wasmtime additions are showing the address mapsection, stack map section, and trap section of a `*.cwasm` file.This new subcommand replaces the infrastructure of the `disas` testsuite, and now that test suite uses `wasmtime objdump` to generate testexpectations. Additionally the subcommand replaces the Pulley `objdump`example as a more full-featured objdump that also works natively withPulley.The hope is that if we add more binary metadata in the future (such asunwinding tables) that can be relatively easily added here forexploration as well. Otherwise this is mostly just a developerconvenience for Wasmtime developers as well and hopefully doesn't costtoo much in maintenance burden.Closes #10336
Add basic support for profiling Pulley (#10034)* Add basic support for profiling PulleyThis commit adds basic support for profiling the Pulley interpreter.This is partially achievable previously
Add basic support for profiling Pulley (#10034)* Add basic support for profiling PulleyThis commit adds basic support for profiling the Pulley interpreter.This is partially achievable previously through the use of nativeprofilers, but the downside of that approach is that you can find hotinstructions but it's not clear in what context the hot instructions arebeing executed nor what functions are hot. The goal of this profiler isto show pulley bytecode and time spent in bytecode itself to betterunderstand the shape of code around a hot instruction to identify newmacro opcodes for example.The general structure of this new profiler is:* There is a compile-time feature for Pulley which is off-by-default where, when enabled, Pulley will record its current program counter into an `AtomicUsize` before each instruction.* When the CLI has `--profile pulley` Wasmtime will spawn a sampling thread in the same process which will periodically read from this `AtomicUsize` to record where the program is currently executing.* The Pulley profiler additionally records all bytecode through the use of the `ProfilingAgent` trait to ensure that the recording has access to all bytecode as well.* Samples are taken throughout the process and emitted to a `pulley-$pid.data` file. This file is then interpreted and printed by an "example" program `profiler-html.rs` in the `pulley/examples` directory.The end result is that hot functions of Pulley bytecode can be seen andinstructions are annotated with how frequently they were executed. Thisenables finding hot loops and understanding more about the whole loop,bytecodes that were selected, and such.* Add missing source file* Check the profile-pulley feature in CI* Miscellaneous fixes for CI* Fix type-checking of `become` on nightly Rust* Fix more misc CI issues* Fix dispatch in tail loop* Update test expectations* Review comments* Fix a feature combo
Support executing Pulley in Wasmtime (#9744)* Support executing Pulley in WasmtimeThis commit is the initial implementation of executing the Pulleyinterpreter from the `wasmtime` crate. This gi
Support executing Pulley in Wasmtime (#9744)* Support executing Pulley in WasmtimeThis commit is the initial implementation of executing the Pulleyinterpreter from the `wasmtime` crate. This gives access to all of the`wasmtime` crate's runtime APIs backed by execution of bytecode inPulley. This builds on the previous PRs I've been making for support inPulley to culminate in testing on CI in this PR. This PR handles somefinal tidbits related to producing a runnable image that can beinterpreted by the `wasmtime` crate such as:* Pulley compilation artifacts are no longer marked as natively executable, just read-only.* Pulley compilation artifacts include wasm-to-array trampolines like normal platforms (removes a pulley special-case).* Dispatch of host calls from Pulley to the Wasmtime runtime are implemented.* Pulley's list of panicking wasm features is slimmed down as most are covered by "this lowering isn't supported" errors.* Execution of wasm code now has an `if` to see whether Pulley is enabled within a `Store` or not.* Traps and basic "unwinding" of the pulley stack are implemented (e.g. a "pulley version" of `setjmp` and `longjmp`, sort of)* Halting the interpreter has been refactored to help shrink the size of `ControlFlow<Done>` and handle metadata with each done state.Some minor refactorings are also included here and there along with afew fixes here and there necessary to get tests passing.The next major part of this commit is updates to our `wast` test suiteand executing all `*.wast` files. Pulley is now executed by default forall files as a new execution engine. This means that all platforms in CIwill start executing Pulley tests. At this time almost all tests areflagged as "expected to fail" but there are a small handful ofallow-listed tests which are expected to pass. This exact list willchange over time as CLIF lowerings are implemented and the interpreteris extended.Follow-up PRs will extend the testing strategy further such as:* Extending `#[wasmtime_test]` to include Pulley in addition to Winch.* Getting testing set up on CI for 32-bit platforms.prtest:full* Fix pulley fuzz build* Fix clippy lints* Shuffle around some `#[cfg]`'d code* Remove unused imports* Update feature sets testing MIRIEnable pulley for wasmtime/wasmtime-cli and also enable all features forwasmtime-environ* Round up pulley's page size to 64k* Skip pulley tests on s390x for now* Add a safety rail for matching a pulley target to the host* Fix more pulley tests on s390x* Review comments* Fix fuzz build
pulley: Add a simple disassembler example (#9656)Should be useful when inspecting `*.cwasm` files since thesystem-default `objdump` doesn't work.