This commit simplifies the selection of an ABI for wasm functions now
that all Cranelift backends implement tail calls. All wasm functions use
the `Tail` calling convention except when the `winch_callable` tunable
is enabled meaning that Winch-generated functions are being called.
This then additionally simplifies the activation of the tail call
proposal. It's not unconditionally active and the same across all
compilers. The Winch compiler is updated to return an error for
unsupported instructions rather than panicking so the embedder API is
suitable for feeding unsupported modules to Winch. This means that tail
calls in Winch behaves similarly to GC in Cranelift or other unsupported
proposals like SIMD in Winch.
* Validate import names given to `trappable_imports`
* Revert "Validate import names given to `trappable_imports`"
This reverts commit 527cb18c49.
* Track which `trappable_imports` names have been used
* Fix the comment on used_trappable_imports_opts
* Move use tracking to `special_case_trappable_error`
This adds support for a newly defined tail-call ABI for s390x
as well as supporting tail calls themselves.
We now use the tail-call ABI by default for Wasmtime, and
enable tail calls by default.
This also allows getting rid of a number of special case
and test exclusions for s390x.
Fixes: https://github.com/bytecodealliance/wasmtime/issues/6530
* Use proper I/O readiness to wait for the shutdown signal instead of an arbitrary timeout.
* Move generic socket setup & teardown code out of the test case.
* Make TcpRead/WriteStream private.
* Return StreamError::Closed when the underlying socket is shut down.
Added an additional LastWrite::Closed status to ensure that the OutputStream _keeps_ closed.
This commit adds a README to the
`wasi-preview1-component-adapter-provider` crate to make it clearer
how to use it and what it's for.
While the README is mostly for those who are already familiar, a
section giving a brief overview of context around the adapters was
added.
Signed-off-by: Victor Adossi <vadossi@cosmonic.com>
In #8873, we stopped tracking the wasi-nn's upstream WIT files
temporarily because it was not clear to me at the time how to implement
errors as CM resources. This PR fixes that, resuming tracking in the
`vendor-wit.sh` and implementing what is needed in the wasi-nn crate.
This leaves several threads unresolved, though:
- it looks like the `vendor-wit.sh` has a new mechanism for retrieving
files into `wit/deps`--at some point wasi-nn should migrate to use
that (?)
- it's not clear to me that "errors as resources" is even the best
approach here; I've opened [#75] to consider the possibility of using
"errors as records" instead.
- this PR identifies that the constructor for errors is in fact
unnecessary, prompting an upstream change ([#76]) that should
eventually be implemented here.
[#75]: https://github.com/WebAssembly/wasi-nn/pull/75
[#76]: https://github.com/WebAssembly/wasi-nn/pull/76
prtest:full
* Cranelift: Stop sign-extending `Imm64` immediates in builder methods
Originally, we sign-extended `Imm64` immediates from their controlling type
var's width to `i64` in the builder methods for `BinaryImm64` and a couple other
instruction formats: https://github.com/bytecodealliance/wasmtime/pull/1687
At some point, we decided that the unused bits in the `Imm64` when the
controlling type var's width is less than 64 should be zero. And we started
asserting that in various places, for example:
87817f38a1/cranelift/codegen/src/machinst/lower.rs (L1237-L1243)
However, we never removed or updated the sign-extension code in the builder
methods. This commit switches the builder methods over to masking the `Imm64` to
just the valid bits, effectively doing a zero extend from the controlling type
var's width instead of a sign extend.
To avoid too much churn in tests, I made `display_inst` print the
sign-extended-from-the-controlling-type-variable's-width value of `Imm64`
immediates. I also made the `Display` implementation for `Imm64` always print in
decimal form with a `-` for negative numbers, rather than the hex it would
previously print for large negative numbers, so that `iconst.i32 0x8000_0000`
doesn't display as `iconst.i32 0xffff_ffff_8000_0000`, which is otherwise pretty
confusing.
* Rename condition
* return new immediates instead of mutating
* Update some test expectations
Don't rely purely on `compile_error!` which doesn't halt compilation.
Instead fill out some stubs which won't ever actually get compiled but
prevent other compiler errors from cropping up.
This fixes a crash where the `GetSp` opcode was overwriting a special
register, so apply a similar filter as to other instructions to ensure
that the special registers are not clobbered.
Also set their default levels to `warn` instead of `deny` to assist with
using clippy locally to avoid compilation failures and collecting as
many as possible in one run. Note that CI will still deny-by-default
through `-Dwarnings`.
Now that we've got CI for Pulley throw in `wasmtime-fiber` as well with
a few extra fixes. This should also help improve the compilation
experience of Wasmtime to 32-bit platforms to hit a more first-class
error about unsupported platforms.
This commit updates `build-test-matrix.js` to calculate PR tests to
never early-return `false`. The current structure for PR tests will
iterate over most matrix entries and filter them out based on whether
they're applicable or not given the commit message and modified files.
The thinking is that an early-return of `false` might be a
false-negative where a later filter enables the test. By only
early-returning `true` this enables any passing predicate to cause the
tests to be run on a PR. Note that this has no effect on merge queues
since those always and unconditionally run everything.
* Add an unsafe API to unload process trap handlers
This commit adds a new unsafe API `Engine::unload_process_handlers`
which can be used to de-initialize trap-handling state in a process. In
general this is an unsafe operation that we have no means of making
safe, hence the `unsafe`. There are particular situations where this can
be done safely though and this is provided for such situations. The
safety conditions rely on invariants that Wasmtime itself cannot
maintain so the burden is on callers to ensure that this is invoked in a
safe manner.
This is inspired by discussion [on Zulip][zulip] where Wasmtime's trap
handling infrastructure prevented unloading a DLL with Wasmtime in it.
There's possibly other reasons that unloading DLLs are unsafe in Rust
but it feels appropriate to at least provide this knob to embedders to
be able to turn if they like.
[zulip]: https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/How.20to.20safely.20drop.20wasmtime.3F/near/453366905
* Review comments
* Update tests/unload-engine.rs
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
* Ignore new test on miri
---------
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
* Derive `Copy` for `Val`
* Fix `clippy::clone_on_copy` for the whole repo
* Enforce `clippy::clone_on_copy` for the workspace
* fix some more clippy::clone_on_copy that got missed
This removes `V128Abi`, which is no longer needed since we removed the native
calling convention from Wasmtime. For the new internal representation of `V128`,
we use an unaligned byte array. This lowers the alignment requirements for
`V128` to 1 rather than 16, which means that `Val` no longer requires padding
after its discriminant before the storage for its `V128` variant, which in turn
allows its size to shrink from 32 to 24 bytes.
Co-authored-by: Trevor Elliott <telliott@fastly.com>
* Add support for `-Wunknown-imports-trap` to components
This was implemented in #8672 and is an easy addition to the CLI.
Closes#9019
* Fix non-component CLI build
* Update gimli to 0.29.0
Gimli 0.29.0 includes a fix for corrupt .eh_frame unwind tables being
generated in certain cases. Wasmtime isn't affected by this as it never
sets an LSDA, but cg_clif will need this for supporting unwinding from
exceptions.
I also had to update a couple of other crates to prevent crates being
included in multiple versions.
* Add vets for new dependencies
---------
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* Pulley: Get tests passing with permissive provenance under MIRI
Co-Authored-By: Alex Crichton <alex@alexcrichton.com>
* Pulley: Get tests passing with strict provenance in MIRI
Co-Authored-By: Alex Crichton <alex@alexcrichton.com>
* Test Pulley under MIRI in CI
* Test Pulley with all cargo features in CI
* Quiet a warning for certain build configs
---------
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* CI: Check that Pulley builds for `no_std` targets
* CI: Test Pulley on 32-bit targets
This adds CI testing for Pulley on the following 32-bit targets:
* `i686-unknown-linux-gnu`
* `armv7-unknown-linux-gnueabihf`
The previous commit added checks that Pulley builds for `no_std` targets.
Our existing test sharding means that it is already tested on a big-endian
platform (`s390x-unknown-linux-gnu`) as well as on different OSes (Linux,
Windows, and macOS).
So altogether we are now testing a pretty wide range of portability dimensions
for Pulley in CI:
* 32- vs. 64-bit architectures
* `std` vs. `no_std`
* Little- vs. big-endian
* Linux vs. Windows vs. macOS
I think our CI coverage for Pulley is in a pretty good place now!
Co-Authored-By: Alex Crichton <alex@alexcrichton.com>
---------
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* Introduce the `pulley-interpreter` crate
This commit is the first step towards implementing
https://github.com/bytecodealliance/rfcs/pull/35
This commit introduces the `pulley-interpreter` crate which contains the Pulley
bytecode definition, encoder, decoder, disassembler, and interpreter.
This is still very much a work in progress! It is expected that we will tweak
encodings and bytecode definitions, that we will overhaul the interpreter (to,
for example, optionally support the unstable Rust `explicit_tail_calls`
feature), and otherwise make large changes. This is just a starting point to get
the ball rolling.
Subsequent commits and pull requests will do things like add the Cranelift
backend to produce Pulley bytecode from Wasm as well as the runtime integration
to run the Pulley interpreter inside Wasmtime.
* remove stray fn main
* Add small tests for special x registers
* Remove now-unused import
* always generate 0 pc rel offsets in arbitrary
* Add doc_auto_cfg feature for docs.rs
* enable all optional features for docs.rs
* Consolidate `BytecodeStream::{advance,get1,get2,...}` into `BytecodeStream::read`
* fix fuzz targets build
* inherit workspace lints in pulley's fuzz crate
* Merge fuzz targets into one target; fix a couple small fuzz bugs
* Add Pulley to our cargo vet config
* Add pulley as a crate to publish
* Move Pulley fuzz target into top level fuzz directory
* Bump MSRV to 1.78.0
This commit updates to use Rust 1.80 in CI as well as updating the
minimum-supported-rust-version to 1.78. Additionally the nightly used in
testing in CI is updated as well.
prtest:full
* Fix compat with latest nightly in tests
* Fix some more nightly warnings
* Ignore new tests on MIRI
* Cranelift(x64): Fix lowering for `store(bitop(x, load(addr)), addr)` for bitops on floats
x86-64 allows us to do these kinds of read-modify-write operations in one
instruction in general, however we also need to ensure that the non-memory
operand is in a GPR. Because Cranelift allows `b{and,or,xor}`s on floating point
types, that means we might need to insert a move from an XMM to a GPR.
Co-Authored-By: Jamey Sharp <jsharp@fastly.com>
* Match all GPR values in `put_in_gpr` and let assertion catch multi-reg values
Instead of backtracking.
---------
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
* Cranelift(x64): provide better panic messages for `Gpr::new(reg).unwrap()` et al
Co-Authored-By: Jamey Sharp <jsharp@fastly.com>
* Fix compile error due to bad mechanical replacement
---------
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
* Add v128.const support to Winch
* Remove next_vr and vector_reg_for methods
* Adjust alignment and slot size for v128
* Forgot to update disas tests
* Update unit tests
* Use 8 byte stack slot sizes
* Fix broken unit tests, add tests for vecs, and use ty size for vecs
* Fix test of wasmtime-fuzzing with `fuzz-pcc` enabled
Allow pcc errors when generating fuzz modules since it's currently gated
as the errors haven't all been weeded out.
* Gate wmemcheck instrumentation more in `wasmtime-cranelift`
This fixes an issue where when the `wmemcheck` feature was enabled it
would unconditionally enable the `wmemcheck`-related instrumentation
around `malloc` and `free`. The fix is to additionally check the runtime
`wmemcheck` setting as well.
Closes#8997
* Forward the `wmemcheck` feature from `wasmtime-cranelift` to `wasmtime-environ`
Not necessarily strictly required but it should help prevent issues
such as #8997 in the future.