This commit fixes an issue with the proxy adapter where if the proxy
program attempted to look at prestat items, which wasi-libc always does
on startup, it would invoke `fd_prestat_get` and receive `ERRNO_NOTSUP`
in response (the standard response when using the
`cfg_filesystem_available!` macro). This error code is unexpected by
wasi-libc and causes wasi-libc to abort. The PR here is to instead
return `ERRNO_BADF` which is indeed expected by wasi-libc and is
recognized as meaning "that prestat isn't available".
* fd_filestat_set test: assert that a file descriptor behaves the same...
whether opened readonly or readwrite.
This test now reproduces the behavior reported in https://github.com/bytecodealliance/wasmtime/issues/7829
Co-authored-by: Trevor Elliott <telliott@fastly.com>
* preview1_path_link test: refactor; create and open file separately
we create and open the file with separate descriptors because the
creation descriptor will always imply writing, whereas the rest do not.
there were a number of auxillary functions in here that were obscuring
what was going on, and making errors harder to read, so i changed some
assertions to use macro-rules so the panic message had the relevant line
number, and i inlined the creation / opening functions.
* preview2 filesystem: track open mode instead of reporting permissions it n DescriptorFlags
FilePerms/DirPerms is a way of having wasmtime-wasi, instead of the operating
system, mediate permissions on a preview2 Descriptor. This was conflated
with the open mode, which should determine whether DescriptorFlags
contains READ or WRITE or MUTATE_DIRECTORY.
We no longer mask FilePerms with the DescriptorFlags (oflags) in open_at -
instead, track what open mode is requested, and see if the file and
directory permissions permit it.
Additionally, File and Dir now track their open_mode (represented using
OpenMode, which just like FilePerms is just a read and write bit),
and report that in DescriptorFlags. Previously, we reported the
FilePerms or DirPerms in the DescriptorFlags, which was totally wrong.
Co-authored-by: Trevor Elliott <telliott@fastly.com>
* different error on windows i guess?
prtest:full
* apparently set-times of read-only is rejected on windows. just skip testing that
* path open read write: another alternate error code for windows
* wasi-common actually gives a badf, so accept either
* this case too
---------
Co-authored-by: Trevor Elliott <telliott@fastly.com>
* Update the wasm-tools family of crates
Pulling in some updates to improve how WIT is managed in this
repository. No changes just yet, however, just pulling in the updates
first.
* Fix tests
* Fix fuzzer build
* Perform stronger typechecks of host-owned resources
Right now the abstraction for host-owned resources in Wasmtime is quite
simple, it's "just an index". This can be error prone because the host
can suffer both from use-after-free and ABA-style problems. While
there's not much that can be done about use-after-free the previous
implementation would accidentally enable "AB" style problems where if a
host-owned resource index was deallocated and then reallocated with
another type the original handle would still work. While not a major bug
this can be confusing and additionally violate's our guarantees as a
component runtime to guests to ensure that resources always have valid
`rep`s going into components.
This commit adds a new layer of storage which keeps track of the
`ResourceType` for all host-owned resources. This means that resources
going into a host-owned table now record their type and coming out of a
host-owned table a typecheck is always performed. Note that guests can
continue to skip this logic as they already have per-type tables and so
won't suffer the same issue.
This change is inspired by my taking a look at #7883. The crux of the
issue was a typo where a resource was reused by accident which led to
confusing behavior due to the reuse. This change instead makes it return
an error more quickly and doesn't allow the component to see any invalid
state.
Closes#7883
* Fix test
* Use generation counters, not types
* Review comments
Rather than an `Arc<RwLock<TypeRegistryInner>>`.
This also removes the `Arc` inside `TypeRegistry` and we effectively reuse
`Engine`'s internal `Arc` instead.
Also, to avoid various `TypeRegistry` methods needing to take an `Engine` to
construct their `RegisteredType` results, but then needing to assert that the
given engine is this registry's engine, I turned the methods into `TypeRegistry`
constructors. These constructors take just an `&Engine` and then access the
underlying `TypeRegistry` as needed, effectively making that property hold
statically.
This is a minor clean up on its own, but is a big help for follow up work I am
doing for Wasm GC and typed function references, where being able to grab a
reference to the engine that a `FuncType` is registered within will prevent
needing to thread in additional engine parameters to various places and then
assert that the engine is the engine that the type is registered within, and
etc...
This commit adds a general purpose lowering for the `fcvt_from_uint`
instruction in addition to the previously specialized lowering for what
the wasm frontend produces. This is unlikely to get triggered much from
the wasm frontend except when intermediate optimizations change the
shape of code. The goal of this commit is to address issues such as
those identified in #7915 and historically by ensuring that there's a
lowering for the instruction for all input types instead of trying to
massage the input into the right form.
This instruction lowering was crafted by studying LLVM's output and I've
put commentary to the best of my ability as to what's going on.
This commit is born out of a fuzz bug on x64 that was discovered recently.
Today, on `main`, and in the 17.0.1 release Wasmtime will panic when compiling
this wasm module for x64:
(module
(func (result v128)
i32.const 0
i32x4.splat
f64x2.convert_low_i32x4_u))
panicking with:
thread '<unnamed>' panicked at /home/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cranelift-codegen-0.104.1/src/machinst/lower.rs:766:21:
should be implemented in ISLE: inst = `v6 = fcvt_from_uint.f64x2 v13 ; v13 = const0`, type = `Some(types::F64X2)`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Bisections points to the "cause" of this regression as #7859 which
more-or-less means that this has always been an issue and that PR just
happened to expose the issue. What's happening here is that egraph
optimizations are turning the IR into a form that the x64 backend can't
codegen. Namely there's no general purpose lowering of i64x2 being
converted to f64x2. The Wasm frontend never produces this but the
optimizations internally end up producing this.
Notably here the result of this function is constant and what's
happening is that a convert-of-a-splat is happening. In lieu of adding
the full general lowering to x64 (which is perhaps overdue since this is
the second or third time this panic has been triggered) I've opted to
add constant propagation optimizations for int-to-float conversions.
These are all based on the Rust `as` operator which has the same
semantics as Cranelift. This is enough to fix the issue here for the
time being.
* unionfind: robustly avoid changing `Idx`s in the GVN map
Stop hoping that keeping the smallest Idx as canonical will yield good
results, and instead explicitly inform the UnionFind of what we expect
not to move.
Fixes#6126
* unionfind: track unions of pinned indices as stats
Emitting a warning in this situation is too much.
* Test with aarch64 macOS on CI
Rebase of #7129 with the `macos-14` string which GitHub indicates should
now work for public repos.
prtest:full
* Fix syntax
This fixes the build on the latest nightly Rust. I was able to vet
`ahash` itself but `zerocopy` is such a large and full-of-unsafe
dependency I've added an exemption for it. The documentation of it seems
to indicate it's a pretty well thought out crate with lots of care
behind it, so at least at a first glance it did not seem overly
worrisome.
* vet: prune lockfile
When running `cargo vet` in #7900, it warned me that we should consider
pruning some unused entries, etc. This is the result of running `cargo
vet prune`.
* vet: a couple more post-#7908
* x64: Refactor multiplication instructions
This commit is inspired after reading over some code from #7865
and #7866. The goal of this commit was to refactor
scalar multiplication-related instructions in the x64 backend to more
closely align with their native instructions. Changes include:
* The `MulHi` instruction is renamed to `Mul`. This represents either
`mul` or `imul` producing a doublewide result.
* A `Mul8` instruction was added to correspond to `Mul` for the 8-bit
variants that produce a doublewide result in the `AX` register rather
than the other instructions which split between `RAX` and `RDX`.
* The `UMulLo` instruction was removed as now it's covered by `Mul`
* The `AluRmiROpcode::Mul` opcode was removed in favor of new `IMul` and
`IMulImm` instructions. Register allocation and emission already had
special cases for `Mul` which felt better as standalone instructions
rather than putting in an existing variant.
Lowerings using `imul` are not affected in general but the `IMulImm`
instruction has different register allocation behavior than before which
allows the destination to have a different register than the first
operand. The `umulhi` and `smulhi` instructions are also reimplemented
with their 8-bit variants instead of extension-plus-16-bit variants.
* Remove outdated emit tests
These are all covered by the filetests framework now too.
* Fix Winch build
* Refactor `wasmtime::FuncType` to hold a handle to its registered type
Rather than holding a copy of the type directly, it now holds a `RegisteredType`
which internally is
* A `VMSharedTypeIndex` pointing into the engine's types registry.
* An `Arc` handle to the engine's type registry.
* An `Arc` handle to the actual type.
The last exists only to keep it so that accessing a `wasmtime::FuncType`'s
parameters and results fast, avoiding any new locking on call hot paths.
This is helping set the stage for further types and `TypeRegistry` refactors
needed for Wasm GC.
* Update the C API for the function types refactor
prtest:full
* rustfmt
* Fix benches build
* winch: Add support for WebAssembly loads/stores
Closes https://github.com/bytecodealliance/wasmtime/issues/6529
This patch adds support for all the instructions involving WebAssembly
loads and stores for 32-bit memories. Given that the `memory64` proposal
is not enabled by default, this patch doesn't include an
implementation/tests for it; in theory minimal tweaks to the
currrent implementation will be needed in order to support 64-bit
memories.
Implemenation-wise, this change, follows a similar pattern as Cranelift
in order to calculate addresses for dynamic/static heaps, the main
difference being that in some cases, doing less work at compile time is
preferred; the current implemenation only checks for the general case of
out-of-bounds access for dynamic heaps for example.
Another important detail regarding the implementation, is the
introduction of `MacroAssembler::wasm_load` and
`MacroAssembler::wasm_store`, which internally use a common
implemenation for loads and stores, with the only difference that the
`wasm_*` variants set the right flags in order to signal that these
operations are not trusted and might trap.
Finally, given that this change introduces support for the last set of
instructions missing for a Wasm MVP, it removes most of Winch's copy of
the spectest suite, and switches over to using the official test suite
where possible (for tests that don't use SIMD or Reference Types).
Follow-up items:
* Before doing any deep benchmarking I'm planning on landing a couple of
improvements regarding compile times that I've identified in parallel
to this change.
* The `imports.wast` tests are disabled because I've identified a bug
with `call_indirect`, which is not related to this change and exists
in main.
* Find a way to run the `tests/all/memory.rs` (or perhaps most of
integration tests) with Winch.
--
prtest:full
* Review comments
Purely mechanical, not functional changes.
This better matches the wording of the spec and of `wasmparser`, especially as
we prepare to implement Wasm GC, where there can be references to concrete types
that are not functions (and are structs or arrays instead).
In #7846 I added `cargo-vet` entries to trust the `windows` crate, just
like we already trust several related `windows-*` crates. I did not,
however, update the lockfile, which means that #7807 continued to fail
the `cargo vet --locked` CI check. This change is the result of simply
running `cargo vet`.
Add a test to expose issues with unbounded recursion through `iadd`
during egraph rewrites, and bound the recursion of
`will_simplify_with_ireduce`.
Fixes#7874
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
* Add function accepting explicit CPU delta time to GuestProfiler
* Remove unused import
* Modify existing signature instead of adding new
* Use qualified Duration instead of import to prevent unused warnings when building without features
* Fix a few egraph rules that needed `subsume`
There were a few rules that dropped value references from the LHS
without using subsume. I think they were probably benign as they
produced constant results, but this change is in the spirit of our
revised guidelines for egraph rules.
* Augment egraph rule guideline 2 to talk about constants
* Cranelift: Use a fixpoint loop to compute the best value for each eclass
Fixes#7857
* Remove fixpoint loop early-continue optimization
* Add document describing optimization rule invariants
* Make select optimizations use subsume
* Remove invalid debug assert
* Remove now-unused methods
* Add commutative adds to cost tests
* Add wasmtime-c-api-impl to the list of crates to publish
* Enable rustdoc and publishing for c-api crate
* Provide paths to c-api headers as cargo links metadata
* Add a README section about using wasm-c-api in a rust crate
* In C API doc comment, mention use case for crates w/ C bindings
* Enable publishing for wasmtime-c-api-macros (prtest:full)
* Move c-api crates later in the publishing sequence (prtest:full)
Looks like it's been awhile since our last update. I've updated the
dependency here and additionally vetted the various dependency upgrades.
I notably did not vet `zstd-sys` since that would require vetting all of
zstd's C implementation itself which I am not, nor do I suspect many of
are, equipped to do. In lieu of that I've updated the exemption of
`zstd-sys` to the newer version.
Closes#7869
* Update and add lots of docs, mostly for components
When I originally implemented the embedding API for the component model
I left a lot of `// TODO: say more here` style comments assuming I'd
come back around before stabilization. While I didn't quite make it in
time for Wasmtime 17 this is my attempt to improve things for the
future. This should add substantive documentation for all component-model
related things and flesh out some more details here and there. Nowhere
near comprehensive but, hey, Rome wasn't built in a day either.
* Update crates/wasmtime/src/runtime/component/component.rs
Co-authored-by: Jeff Parsons <jeff@parsons.io>
* Update crates/wasmtime/src/runtime/component/component.rs
Co-authored-by: Jeff Parsons <jeff@parsons.io>
---------
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
Co-authored-by: Jeff Parsons <jeff@parsons.io>
* Add C API for GuestProfiler
* GuestProfiler C API: remove unsafe and add docs
* Fix clang-format complaints
* rename to wasmtime_guestprofiler_t for consistency, change to passing tuples by struct type, clarify docs
* rustfmt
* out is marked "own" too
* gate on profiling feature
* mpk: enable MPK if available in CI
After discussing several options for testing MPK in CI, this stopgap
measure at least provides some coverage. Other options include
maintaining a separate MPK-enabled CI runner (configuration is not
transparent, hard to maintain) or running the MPK-enabled tests in a
system-mode QEMU VM (tricky to get right, also hard to maintain). For
now, those of us at the Cranelift meeting agreed this at least gets some
CI testing for the MPK bits, which shouldn't be changing too often.
Since not all GitHub runners have MPK available, we only set the
`WASMTIME_TEST_FORCE_MPK` environment variable when it is. This change
also emits a warning to the GitHub logs in either case for easier
troubleshooting (e.g., to attempt to provide context if MPK logic breaks
and is only found in a later CI run).
prtest:full
* review: create a separate matrix entry
As requested by @alexcrichton, this change limits the MPK testing (and
the associated warnings) to a new matrix target: `Test Linux x86_64 with
MPK`.
* Fix handling of `Tunables` on cross-compiles
This commit fixes how Wasmtime handles `Tunables` when targetting
non-host platforms (or namely platforms with different pointer widths).
Previously the host's `Tunables` would always be used instead of the
target's tunables which meant that modules couldn't be loaded on the
other platform due to the host having differing tunables by default.
This commit updates tunables in `wasmtime::Config` to all be optional
and loading the actual `Tunables` is deferred until the target is known
during `Engine`-creation time.
* Fix warning
Alex Crichton
Pat Hickey
Nick Fitzgerald
Archisman Mridha
Maja Kądziołka
Milek7
Dave Bakker
Trevor Elliott
Andrew Brown
Saúl Cabrera
Matheus Cardoso
Fredrik Fornwall
Max Brunsfeld
yowl
wasmtime-publish
Afonso Bordado
edoardo marangoni
jianjunz