When we compute the amount of space that we need in a stack frame for
the stack limit check, we were only counting spill-slots and explicit
stack-slots. However, we need to account for all uses of the stack which
occur before the next stack limit check. That includes clobbers and any
stack arguments we want to pass to callees.
The maximum amount that we could have missed by is essentially bounded
by the number of arguments which could be passed to a function. In
Wasmtime, that is limited by `MAX_WASM_FUNCTION_PARAMS` in
`wasmparser::limits`, which is set to 1,000, and the largest arguments
are 16-byte vectors, so this could undercount by about 16kB.
This is not a security issue according to Wasmtime's security policy
(https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html)
because it's the embedder's responsibility to ensure that the stack
where Wasmtime is running has enough extra space on top of the
configured `max_wasm_stack` size, and getting within 16kB of the host
stack size is too small to be safe even with this fixed.
However, this was definitely not the intended behavior when stack limit
checks or stack probes are enabled, and anyone with non-default
configurations or non-Wasmtime uses of Cranelift should evaluate whether
this bug impacts your use case.
(For reference: When Wasmtime is used in async mode or on Linux, the
default stack size is 1.5MB larger than the default WebAssembly stack
limit, so such configurations are typically safe regardless. On the
other hand, on macOS the default non-async stack size for threads other
than the main thread is the same size as the default for
`max_wasm_stack`, so that is too small with or without this bug fix.)
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
This commit fixes an accidental regression from #7766 where
`infer_native_flags` is called even if a target is explicitly specified
to a `Config`. Now inference only happens if a target isn't specified
meaning that the host is selected.
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* cranelift: Fix ireduce rules (#8005)
We had two optimization rules which started off like this:
(rule (simplify (ireduce smallty val@(binary_op _ op x y)))
(if-let _ (reducible_modular_op val))
...)
This was intended to check that `x` and `y` came from an instruction
which not only was a binary op but also matched `reducible_modular_op`.
Unfortunately, both `binary_op` and `reducible_modular_op` were
multi-terms.
- So `binary_op` would search the eclass rooted at `val` to find each
instruction that uses a binary operator.
- Then `reducible_modular_op` would search the entire eclass again to
find an instruction which matched its criteria.
Nothing ensured that both searches would find the same instruction.
The reason these rules were written this way was because they had
additional guards (`will_simplify_with_ireduce`) which made them fairly
complex, and it seemed desirable to not have to copy those guards for
every operator where we wanted to apply this optimization.
However, we've decided that checking whether the rule is actually an
improvement is not desirable. In general, that should be the job of the
cost function. Blindly adding equivalent expressions gives us more
opportunities for other rules to fire, and we have global recursion and
growth limits to keep the process from going too wild.
As a result, we can just delete those guards. That allows us to write
the rules in a more straightforward way.
Fixes#7999.
Co-authored-by: Trevor Elliott <telliott@fastly.com>
Co-authored-by: L Pereira <l.pereira@fastly.com>
Co-authored-by: Chris Fallin <chris@cfallin.org>
* Update RELEASES.md
* Update RELEASES.md
---------
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
Co-authored-by: L Pereira <l.pereira@fastly.com>
Co-authored-by: Chris Fallin <chris@cfallin.org>
* Preview 2 filesystem: track open_mode instead of reporting the permissions (#7876)
* 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>
* Return correct fs errors on the proxy adapter (#7926)
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".
* Make wasi-common self-contained, deprecate exports from wasmtime-wasi (#7881)
* WIP: try to make wasi-common self contained.
* rebase: cargo.lock
* remove all dependencies between wasi-common and wasmtime-wasi
* use wasi-common directly throughout tests, benches, examples, cli run
* wasi-threads: use wasi-common's maybe_exit_on_error in spawned thread
not a very modular design, but at this point wasi-common and
wasi-threads are forever wed
* fix wasmtime's docs
* re-introduce wasmtime-wasi's exports of wasi-common definitions behind deprecated
* factor out determining i32 process exit code
and remove libc dep because rustix provides the same constant
* commands/run: inline the logic about aborting on trap
since this is the sole place in the codebase its used
* Add high-level summary to wasi-common's top-level doc comment.
* c-api: fix use of wasi_cap_std_sync => wasi_common::sync, wasmtime_wasi => wasi_common
* fix tokio example
* think better of combining downcast and masking into one method
* fix references to wasmtime_wasi in docs
prtest:full
* benches: use wasi-common
* cfg-if around use of rustix::process because that doesnt exist on windows
* wasi-common: include tests, caught by verify-publish
* fix another bench
* exit requires wasmtime dep. caught by verify-publish.
---------
Co-authored-by: Trevor Elliott <telliott@fastly.com>
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
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>
* 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)
* 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
Using an epoch of `1` and setting its duration to the full timeout
configured does not work for `wasmtime serve`, as the epoch is counted
globally per engine. This commit switches to dividing the timeout by 10,
and expiring an instance after 11 epochs have been observed, giving a
maximum overshoot of 10%.
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
Like the rest of the `windows-*` crates published by Kenny Kerr, this
change also adds the `windows` crate itself to the trusted list. This is
necessary for use in #7807.
Simplify the implementation of the serve command by removing the
explicit Service trait impl, and using `service_fn` instead.
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
This commit updates the `wasmtime` crate itself to have the
`component-model` feature enabled by default. This was also done for the
CLI but only for clarity because the `component-model` feature was
already eanbled by default transitively through the `serve` feature.
Don't force-enable the `wasmtime-wast` crate if the `component-model`
feature is active, only activate component model support if
`wasmtime-wast` is otherwise activated.
* Shuffle some items around in `wasmtime`
This is a follow-up to #7766 with some more changes and reorganization.
These are some small items here and there which shouldn't have any
actual impact on functionality but are intended to reorganize a bit.
Changes here include:
* Move component artifact definitions to `wasmtime-environ` as core
module ones already live there.
* Rename the module with module artifacts from `instantiate` to
`module_artifacts`.
* Make `wasmtime-jit-icache-coherence` an optional dependency as only
the `runtime` feature requires it.
* Reorganize serialized metadata for wasmtime ELF files to consolidate
everything back into `wasmtime::engine::serialization`. This is to
prevent the definition of the serialization format being spread across
a few files.
* Touching up the `serialization` module to compile in all builds of the
`wasmtime` crate.
* fix docs typo
---------
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
Currently translation of Wasm code uses the `FUNCREF_MASK` constant
which has type `usize` but this type is not always appropriate in
cross-compiled situations. This commit fixes the usage of `FUNCREF_MASK`
by using the platform-independent value (a negative value) along with
some extra asserts and an explantation of how to update if necessary.
Purely mechanical, no functional changes.
This is to help differentiate between value types (i32, i64, reference types,
etc...) and defined types (function signatures, struct definitions, array
definitions).
* Add `runtime` feature to `wasmtime` crate
This feature can be disabled to build `wasmtime` only for compilation.
This can be useful when cross-compiling, especially on a target that
can't run wasmtime itself (e.g. `wasm32`).
* prtest:full
* don't round pages without runtime feature
* fix async assertions
* move profiling into runtime
* enable runtime for wasmtime-wasi
* enable runtime for c-api
* fix build_artifacts in non-cache case
* fix miri extensions
* enable runtime for wast
* enable runtime for explorer
* support cranelift all-arch on wasm32
* add doc links for `WeakEngine`
* simplify lib runtime cfgs
* move limits and resources to runtime
* move stack to runtime
* move coredump and debug to runtime
* add runtime to coredump and async features
* add wasm32 build job
* combine engine modules
* single compile mod
* remove allow for macro paths
* add comments
* wasmtime: Rename `SignatureFooBar` to `TypeFooBar`
No functional changes, just the following mechanical renames:
* `VMSharedSignatureIndex` to `VMSharedTypeIndex`
* `SignatureIndex` to `TypeIndex`
* `SignatureRegistry` to `TypeRegistry`
* and more
This is intended to start paving the way for Wasm GC support, where there are
more than just function signatures in a Wasm module's type section, and we are
going to need to register non-function-signature types in the registry as well,
for things like casting between reference types and passing reference types
across Wasm modules.
* Reintroduce different index types for module-interned types vs Wasm-index-space types
* Fix a couple unused-import warnings
* feat: support component instance import type introspection
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* refactor: implement `import_types` on `Linker`
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* refactor: flatten `types::ComponentItem` members
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* refactor: remove `types` re-exports
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* feat: implement component type introspection
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* chore: derive `Debug` for `Field`
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* refactor: return `ExactSizeIterator` for component function parameters/results
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* tests: add `introspection` test
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* chore: derive `Clone` on `ComponentItem` types
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* feat: support module and instance type introspection
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
---------
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* Break more data dependencies in float-related instructions
This commit takes a stab at #7816 without diving a whole lot into it. I
noticed that the loop started with `vcvtss2sd` which is along the same
lines as previous false dependencies found earlier in PRs such as #7098.
I had forgotten these instructions at the time and meant to go back and
touch them up and #7731 has provided sufficient motivation to do so!
Locally this takes that test case from 1.6s to 0.4s for me.
* Fix inst emit tests
* Update winch codegen
* Enable all winch tests on windows
prtest:mingw-x64
* Plumb through x64 unwind info creation
* Add the frame regs unwind info
* Emit UnwindInfo::SaveReg instructions
* Review feedback
* Comment the offset_downward_to_clobbers value
* Enable the component model by default
This commit enables the component model by default in the embedding API
and the CLI. This means that an opt-in of `-W component-model` is no
longer required and additionally `.wasm_component_model(true)` is no
longer required. Note that this won't impact existing embeddings since
the component model feature doesn't do much less `wasmtime::component`
is used, and if that's being used this is probably good news for you.
* Fix non-component model build
* WASI: copy in the version 0.2.0 wits
* wasmtime's wits: use versions 0.2.0 of wasi packages
* bindgens and other fixed version strings: change 0.2.0-rc-etc to 0.2.0
Previously temporary streams created as part of the preview1 adapter in
the wasmtime-wasi crate were left open which meant that they continued
to occupy space in the resource table and the underlying file
accidentally wasn't ever actually closed.
cc #7813