This commit updates the "integrating with Wasmtime" link in
crates/wiggle/README.md which currently results in a 404 Not Found.
I hope the link in this commit is correct, but if not hopefully someone
will point out the correct page this link should point to if this is not
the case.
Signed-off-by: Daniel Bevenius <daniel.bevenius@gmail.com>
* delete adapter src/main.o: this was accidentally left out of #165
* move adapter, byte-array, and verify to a new workspace
* rename byte-array crate to a name available on crates.io
* add a readme for verify, also give it a slightly better name
* CI: wit dep check in its own step, verify before publish, trim down publication
* reactor-tests: delete deps symlinks
* reactor-tests: manage wit with wit-deps
* test: dont set default toolchain to nightly
* wit-deps lock adapter
* wit-deps lock reactor-tests
wit-deps doesnt manage these for some reason
* Update coredump generation in the cli to use wasm_encoder
* Add deny.toml exception for wasm-encoder 0.25.0
* add missing newline
* update custom section in fuzzing crate
It was an alias, defined in `build.rs`, for
cfg(any(feature = "cranelift", feature = "winch"))
But it wasn't actually saving us much typing because we also have to have
#[cfg_attr(nightlydoc, doc(cfg(any(feature = "cranelift", feature = "winch"))))]
for all the public APIs that are gated on a compiler being present so that the
API docs show which methods require which features.
So I'm removing it and using the full `cfg(any(..))` form instead.
This allows us to remove a `build.rs` that is otherwise unused and helps
`rust-analyzer` give better code completions and jump-to-definitions and things.
* Fold guest profiling flags into `--profile` CLI option
This commit removes the `--profile-guest` and `--profile-guest-interval`
CLI flags and folds them into the preexisting `--profile` flag.
Specifying guest profiling can now be done with `--profile guest` which
has a default path/interval to write to. The path/interval can be
configured with `--profile guest,path.json` and `--profile
guest,path.json,10ms`.
* Update src/commands/run.rs
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
---------
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
* Reorganize profiling-related code
This commit is a bit of reorganization around profiling-related code in
Wasmtime with the aim of eventually simplifying it a bit more. The
changes here are:
* All exposed agents are removed and instead only constructor functions
returning trait objects are now exposed.
* All `*_disabled.rs` files and modules are removed in favor of a
function that returns a result (less trait impls).
* All `*_linux.rs` files where renamed to just `*.rs`. (less files in
play)
* The `pid` and `tid` arguments were removed as they were only used by
the jitdump profiler and now that manages it internally.
* Registering an entire ELF image is now part of the trait rather than
buried within the trampoline code in Wasmtime.
* Remove DWARF support from jitdump
In general Wasmtime's support for DWARF is not great so this is rarely
used and at least in my experience this hasn't been necessary to get
good information from perf. This commit removes the processing here
which while probably useful is probably not necessary and otherwise
makes the jidump agent a bit of an odd-one-out relative among the other
agents.
* Remove now no-longer-needed `dbg_image` argument
* Only grab the jitdump lock once-per-module
Refactor slightly to account for this.
* Fill in the `tid` argument to jitump
This has been the same as `self.pid` for quite some time but with
`rustix` it's pretty easy to get access to the current thread id.
* Merge module/trampoline registration for profilers
Add a second argument to registration of an entire module for custom
names to get functions named correctly, and otherwise profilers now only
need to look at individual functions.
* Fixup vtune support
* Delete no-longer-needed accessors
Closes#6328
* Remove unused import
* Fix a portability issue with u32-vs-i32
Bake in the `*mut VMContext` to `&mut Instance` translation into the
macro-generated trampolines to avoid the need to use
`Instance::from_vmctx` with an extra level of indentation everywhere.
Additionally some libcalls are now entirely safe code as their one
unsafe operation was the `VMContext` to `Instance` translation.
* Make Wasmtime compatible with Stacked Borrows in MIRI
The fact that Wasmtime executes correctly under Tree Borrows but not
Stacked Borrows is a bit suspect and given what I've since learned about
the aliasing models I wanted to give it a stab to get things working
with Stacked Borrows. It turns out that this wasn't all that difficult,
but required two underlying changes:
* First the implementation of `Instance::vmctx` is now specially crafted
in an intentional way to preserve the provenance of the returned
pointer. This way all `&Instance` pointers will return a `VMContext`
pointer with the same provenance and acquiring the pointer won't
accidentally invalidate all prior pointers.
* Second the conversion from `VMContext` to `Instance` has been updated
to work with provenance and such. Previously the conversion looked
like `&mut VMContext -> &mut Instance`, but I think this didn't play
well with MIRI because `&mut VMContext` has no provenance over any
data since it's zero-sized. Instead now the conversion is from `*mut
VMContext` to `&mut Instance` where we know that `*mut VMContext` has
provenance over the entire instance allocation. This shuffled a fair
bit around to handle the new closure-based API to prevent escaping
pointers, but otherwise no major change other than the structure and
the types in play.
This commit additionally picks up a dependency on the `sptr` crate which
is a crate for prototyping strict-provenance APIs in Rust. This is I
believe intended to be upstreamed into Rust one day (it's in the
standard library as a Nightly-only API right now) but in the meantime
this is a stable alternative.
* Clean up manual `unsafe impl Send` impls
This commit adds a new wrapper type `SendSyncPtr<T>` which automatically
impls the `Send` and `Sync` traits based on the `T` type contained.
Otherwise it works similarly to `NonNull<T>`. This helps clean up a
number of manual annotations of `unsafe impl {Send,Sync} for ...`
throughout the runtime.
* Remove pointer-to-integer casts with tables
In an effort to enable MIRI's "strict provenance" mode this commit
removes the integer-to-pointer casts in the runtime `Table`
implementation for Wasmtime. Most of the bits were already there to
track all this, so this commit plumbed around the various pointer types
and with the help of the `sptr` crate preserves the provenance of all
related pointers.
* Remove integer-to-pointer casts in CoW management
The `MemoryImageSlot` type stored a `base: usize` field mostly because I
was too lazy to have a `Send`/`Sync` type as a pointer, so this commit
updates it to use `SendSyncPtr<u8>` and then plumbs the pointer-ness
throughout the implementation. This removes all integer-to-pointer casts
and has pointers stores as actual pointers when they're at rest.
* Remove pointer-to-integer casts in "raw" representations
This commit changes the "raw" representation of `Func` and `ExternRef`
to a `*mut c_void` instead of the previous `usize`. This is done to
satisfy MIRI's requirements with strict provenance, properly marking the
intermediate value as a pointer rather than round-tripping through
integers.
* Minor remaining cleanups
* Switch to Stacked Borrows for MIRI on CI
Additionally enable the strict-provenance features to force warnings
emitted today to become errors.
* Fix a typo
* Replace a negative offset with `sub`
* Comment the sentinel value
* Use NonNull::dangling
* Remove the initializer from a global's type information
This commit removes the `Global::initializer` field to instead only
store type information about the global rather than its initialization
state. Instead now the initializer is stored separately from the type of
the global, and only for defined globals. This removes the need in a few
locations to synthesize dummy initializers.
* Actually delete what I intended to delete
* Simplify global initializer loop
* Remove lingering references to `experimental_x64`
This hasn't been experimental for quite a long time now and these are
all mostly old vestiges of when the current backend was under
development, so remove them all as they're no longer necessary.
* Try to fix test
* Try again to fix tests
* wasi: add the `wasi-testsuite` tests for wasi-common
As described [here], this uses the `prod/testsuite-base` branch in which
the tests are built as `.wasm` files.
[here]: https://github.com/WebAssembly/wasi-testsuite/#getting-started
* chore: update `walkdir` everywhere to its latest version
This is done in order to use it for `wasi_testsuite` testing.
* vet: extend `walkdir`'s exemption
* test: factor out `get_wasmtime_command`
This will be helpful for `wasi_testsuite` testing.
* test: use all `wasi-testsuite` test cases
This change alters the `wasi_testsuite` test to run all of the available
test cases in [wasi-testsuite]. This involved making the test runner a
bit more robust to the various shapes of JSON specifications in that
project. Unfortunately, the `wasi_testsuite` test fails some of the
cases, so I added a `WASI_COMMON_IGNORE_LIST` to avoid these
temporarily. (This may remind some of the Wasm testsuite ignore lists in
Cranelift; those relied on `build.rs` to create a `#[test]` for each
test case, which I felt is not yet needed here).
It's unclear to me why the tests are failing. It could be because:
- wasi-common has a bug
- wasi-testsuite overspecifies (or incorrectly specifies) a test
- the test runner incorrectly configures Wasmtime's CLI execution.
But this change makes it easier to resolve this. Remove the file from
`WASI_COMMON_IGNORE_LIST` and run `cargo test wasi_testsuite --
--nocapture`. The printed output will show the expected result, the
actual result, and a command to replicate the failure from the command
line.
[wasi-testsuite]: https://github.com/WebAssembly/wasi-testsuite
* review: add "shrinking" comment
* Unify differential result comparison logic
Execution of functions handles the case where one instance stack
overflows and the other didn't, but instantiation didn't handle this
case. This commit fixes this issue by sharing the result comparison
logic between the two branches.
* Update crates/fuzzing/src/oracles.rs
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
---------
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
* Run some tests in MIRI on CI
This commit is an implementation of getting at least chunks of Wasmtime
to run in MIRI on CI. The full test suite is not possible to run in MIRI
because MIRI cannot run Cranelift-produced code at runtime (aka it
doesn't support JITs). Running MIRI, however, is still quite valuable if
we can manage it because it would have trivially detected
GHSA-ch89-5g45-qwc7, our most recent security advisory. The goal of this
PR is to select a subset of the test suite to execute in CI under MIRI
and boost our confidence in the copious amount of `unsafe` code in
Wasmtime's runtime.
Under MIRI's default settings, which is to use the [Stacked
Borrows][stacked] model, much of the code in `Instance` and `VMContext`
is considered invalid. Under the optional [Tree Borrows][tree] model,
however, this same code is accepted. After some [extremely helpful
discussion][discuss] on the Rust Zulip my current conclusion is that
what we're doing is not fundamentally un-sound but we need to model it
in a different way. This PR, however, uses the Tree Borrows model for
MIRI to get something onto CI sooner rather than later, and I hope to
follow this up with something that passed Stacked Borrows. Additionally
that'll hopefully make this diff smaller and easier to digest.
Given all that, the end result of this PR is to get 131 separate unit
tests executing on CI. These unit tests largely exercise the embedding
API where wasm function compilation is not involved. Some tests compile
wasm functions but don't run them, but compiling wasm through Cranelift
in MIRI is so slow that it doesn't seem worth it at this time. This does
mean that there's a pretty big hole in MIRI's test coverage, but that's
to be expected as we're a JIT compiler after all.
To get tests working in MIRI this PR uses a number of strategies:
* When platform-specific code is involved there's now `#[cfg(miri)]` for
MIRI's version. For example there's a custom-built "mmap" just for
MIRI now. Many of these are simple noops, some are `unimplemented!()`
as they shouldn't be reached, and some are slightly nontrivial
implementations such as mmaps and trap handling (for native-to-native
function calls).
* Many test modules are simply excluded via `#![cfg(not(miri))]` at the
top of the file. This excludes the entire module's worth of tests from
MIRI. Other modules have `#[cfg_attr(miri, ignore)]` annotations to
ignore tests by default on MIRI. The latter form is used in modules
where some tests work and some don't. This means that all future test
additions will need to be effectively annotated whether they work in
MIRI or not. My hope though is that there's enough precedent in the
test suite of what to do to not cause too much burden.
* A number of locations are fixed with respect to MIRI's analysis. For
example `ComponentInstance`, the component equivalent of
`wasmtime_runtime::Instance`, was actually left out from the fix for
the CVE by accident. MIRI dutifully highlighted the issues here and
I've fixed them locally. Some locations fixed for MIRI are changed to
something that looks similar but is subtly different. For example
retaining items in a `Store<T>` is now done with a Wasmtime-specific
`StoreBox<T>` type. This is because, with MIRI's analyses, moving a
`Box<T>` invalidates all pointers derived from this `Box<T>`. We don't
want these semantics, so we effectively have a custom `Box<T>` to suit
our needs in this regard.
* Some default configuration is different under MIRI. For example most
linear memories are dynamic with no guards and no space reserved for
growth. Settings such as parallel compilation are disabled. These are
applied to make MIRI "work by default" in more places ideally. Some
tests which perform N iterations of something perform fewer iterations
on MIRI to not take quite so long.
This PR is not intended to be a one-and-done-we-never-look-at-it-again
kind of thing. Instead this is intended to lay the groundwork to
continuously run MIRI in CI to catch any soundness issues. This feels,
to me, overdue given the amount of `unsafe` code inside of Wasmtime. My
hope is that over time we can figure out how to run Wasm in MIRI but
that may take quite some time. Regardless this will be adding nontrivial
maintenance work to contributors to Wasmtime. MIRI will be run on CI for
merges, MIRI will have test failures when everything else passes,
MIRI's errors will need to be deciphered by those who have probably
never run MIRI before, things like that. Despite all this to me it seems
worth the cost at this time. Just getting this running caught two
possible soundness bugs in the component implementation that could have
had a real-world impact in the future!
[stacked]: https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md
[tree]: https://perso.crans.org/vanille/treebor/
[discuss]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Tree.20vs.20Stacked.20Borrows.20.26.20a.20debugging.20question
* Update alignment comment
* wasmtime: Fix resetting stack-walking registers when entering/exiting Wasm
Fixes a regression from #6262, originally reported in
https://github.com/bytecodealliance/wasmtime-dotnet/pull/245
The issue was that we would enter Wasm and save the stack-walking registers but
never clear them after Wasm returns. Then if a host-to-host call tried to
capture a stack, we would mistakenly attempt to use those stale registers to
start the stack walk. This mistake would be caught by an assertion, triggering a
panic.
This commit fixes the issue by managing the save/restore in the
`CallThreadState` construction/drop, rather than in the old `set_prev`
method.
Co-Authored-By: Alex Crichton <alex@alexcrichton.com>
* Plumb through `VMRuntimeLimits` when capturing stack traces
This way we can differentiate between the same module loaded in different stores
and avoid leaking other stores' frames into our backtraces.
Co-Authored-By: Jamey Sharp <jsharp@fastly.com>
---------
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
The previous timeout was 20 seconds which while it won't ever time out
on OSS-Fuzz a wasm module is highly unlikely to do anything interesting
past the first bit as if it takes longer it's probably an uninteresting
infinite loop. Additionally this should improve loading a whole corpus
as test cases won't randomly take 20 seconds to load.
* winch: Handle relocations and traps
This change introduces handling of traps and relocations in Winch, which
was left out in https://github.com/bytecodealliance/wasmtime/pull/6119.
In order to so, this change moves the `CompiledFunction` struct to the
`wasmtime-cranelift-shared` crate, allowing Cranelift and Winch to
operate on a single, shared representation, following some of the ideas
discussed in https://github.com/bytecodealliance/wasmtime/pull/5944.
Even though Winch doesn't rely on all the fields of `CompiledFunction`,
it eventually will. With the addition of relocations and traps it
started to be more evident that even if we wanted to have different
representations of a compiled function, they would end up being very
similar.
This change also consolidates where the `traps` and `relocations` of the
`CompiledFunction` get created, by introducing a constructor that
operates on a `MachBufferFinalized<Final>`, esentially encapsulating
this process in a single place for both Winch and Cranelift.
* Rework the shared `CompiledFunction`
This commit reworks the shared `CompiledFunction` struct. The compiled
function now contains the essential pieces to derive all the information
to create the final object file and to derive the debug information for
the function.
This commit also decouples the dwarf emission process by introducing
a `metadata` field in the `CompiledFunction` struct, which is used as
the central structure for dwarf emission.
* Improve longevity for fuzzing corpus of wasm modules
This commit is an improvement to the longevity of Wasmtime's corpus of
fuzz inputs to the `instantiate` fuzzer. Currently the input to this
fuzzers is arbitrary binary data which is a "DNA" of sorts of what to
do. This DNA changes over time as we update the fuzzer and add
configuration options, for example. When this happens though the
meaning of all existing inputs in the corpus changes because they all
have slightly different meanings now. The goal of this commit is to
improve the usefulness of a historical corpus, with respect to the
WebAssembly modules generated, across changes to the DNA.
A custom mutator is now provided for the `instantiate` fuzzer. This
mutator will not only perform libfuzzer's default mutation for the input
but will additionally place an "envelope" around the fuzz input. Namely,
the fuzz input is encoded as a valid WebAssembly module where the actual
input to the fuzzer is a trailing custom section. When the fuzzer runs
over this input it will read the custom section, perform any
configuration generation necessary, and then use the envelope module as
the actual input to the fuzzer instead of whatever was generated from
the fuzz input. This means that when a future update is made to the DNA
of a module the interpretation of the fuzz input section will change but
the module in question will not change. This means that any interesting
shapes of modules with respect to instructions should be preserved over
time in theory.
Some consequences of this strategy, however, are:
* If the DNA changes then it's difficult to produce minor mutations of
the original module. This is because mutations generate a module based
on the new DNA which is likely much different than the preexisting
module. This mainly just means that libFuzzer will have to rediscover
how to mutate up into interesting shapes on DNA changes but it'll
still be able to retain all the existing interesting modules.
Additionally this can be mitigate with the integration of
`wasm-mutate` perhaps into these fuzzers as well.
* Protection is necessary against libFuzzer itself with respect to the
module. The existing fuzzers only expect valid modules to be created,
but libFuzzer can now create mutations which leave the trailing
section in place, meaning the module is no longer valid. One option is
to record a cryptographic hash in the fuzz input section of the
previous module, only using the module if the hashes match. This
approach will not work over time in the face of binary format changes,
however. For example the multi-memory proposal changed binary
encodings a year or so ago meaning that any previous fuzz-generated
cases would no longer be guaranteed to be valid. The strategy settled
by this PR is to pass a flag to the execution function indicating if
the module is "known valid" and gracefully handle error if it isn't
(for example if it's a prior test case).
I'll note that this new strategy of fuzzing is not applied to the
`differential` fuzzer. This could theoretically use the same strategy
but it relies much more strictly on being able to produce a module with
properties like NaN canonicalization, resource limits, fuel to limit
execution, etc. While it may be possible to integrate this with
`differential` in the future I figured it'd be better to start with the
`instantiate` fuzzer and go from there.
* Fix doc build
* wasmtime: In-process sampling profiler
Unlike the existing profiling options, this works on all platforms and
does not rely on any external profiling tools like perf or VTune. On the
other hand, it can only profile time spent in the WebAssembly guest, not
in Wasmtime itself or other host code. Also it can't measure time as
precisely as platform-native tools can.
The profile is saved in the Firefox processed format, which can be
viewed using https://profiler.firefox.com/.
* Ensure func_offset is populated
* Refactor
* Review comments
* Move GuestProfiler to the wasmtime crate
* Document the new GuestProfiler API
* Add TODO comments for future work
* Use module_offset, not func_offset, as fallback PC
* Minimize work done during `sample()`
Use fxprof_processed_profile's support for looking up symbols to avoid
looking up the same PC more than once per profile.
* Keep profiler state in the store
Also extend the documentation based on review comments.
* Import debugid audit from Mozilla again
* Split out platform-specific logic for `Mmap`
This commit refactors the implementation of the `wasmtime_runtime::Mmap`
structure to have the platform-specific bits separated by file rather
than interspersed throughout `mmap.rs`. I plan in the near future to add
a faux implementation for `cfg(miri)` to get some tests running with
miri on CI.
At the same time this additionally updates the interface of `Mmap` to be
more miri-friendly in the sense of ensuring that mutability is all in
the right place and we don't eagerly mark items as safe too soon. For
example it seems questionable that previously you could get a mutable
slice to readonly memory. Probably not going to cause any issues, but
this interface should hopefully be more verification-friendly.
* Fix tests on Windows
This commit updates the test case generation for the `component_api`
fuzzer to prepare for an update to the `arbitrary` crate. The current
algorithm, with the latest `arbitrary` crate, generates a 20MB source
file which is a bit egregious. The goal here was to get that under
control by altering the parameters of test case generation and
additionally changing the structure of what's generated.
The new strategy is to have a limited set of "type fuel" which is
consumed as a type is generated. This bounds the maximal size of a type
in addition to its depth as prior. Additionally a fixed set of types are
generated first and then test cases select from these types as opposed
to test cases always generating types for themselves. Coupled together
this brings the size of the generated file back into the 200K range as
it was before.
* Slightly shrink compiled wasm modules
This commit shuffles trampolines to the end of a compiled ELF file
instead of interspersed throughout. Additionally trampolines are no
longer given a higher alignment requirement than is required by the ISA
as is given to functions since they're not perf critical.
The savings here are quite minor, only 0.3% locally on
spidermonkey.wasm.
* Fix winch compile
* Return a more descriptive `FunctionAlignment` from `TargetIsa`
* Push alignment further into Cranelift
Remove the need for taking a function's alignment and an ISA's alignment
and combining them, instead only using the function's alignment as the
source of truth.
* Review comments
Move the setup/teardown of contexts for each function's compile into a
new `FunctionCompiler` structure which handles more internally between
trampolines and normal wasm functions.
We only have caller-checked function references, and it is unlikely we will have
any other kind for quite a long time.
Also remove all old `anyfunc`s and replace them with some variation of
`func_ref`.
Also consolidate style to use `func_ref` instead of `funcref` except when that
would be a breaking change to the public API or a comment is using the `funcref`
shorthand from WAT.
This commit splits `VMCallerCheckedFuncRef::func_ptr` into three new function
pointers: `VMCallerCheckedFuncRef::{wasm,array,native}_call`. Each one has a
dedicated calling convention, so callers just choose the version that works for
them. This is as opposed to the previous behavior where we would chain together
many trampolines that converted between calling conventions, sometimes up to
four on the way into Wasm and four more on the way back out. See [0] for
details.
[0] https://github.com/bytecodealliance/rfcs/blob/main/accepted/tail-calls.md#a-review-of-our-existing-trampolines-calling-conventions-and-call-paths
Thanks to @bjorn3 for the initial idea of having multiple function pointers for
different calling conventions.
This is generally a nice ~5-10% speed up to our call benchmarks across the
board: both Wasm-to-host and host-to-Wasm. The one exception is typed calls from
Wasm to the host, which have a minor regression. We hypothesize that this is
because the old hand-written assembly trampolines did not maintain a call frame
and do a tail call, but the new Cranelift-generated trampolines do maintain a
call frame and do a regular call. The regression is only a couple nanoseconds,
which seems well-explained by these differences explain, and ultimately is not a
big deal.
However, this does lead to a ~5% code size regression for compiled modules.
Before, we compiled a trampoline per escaping function's signature and we
deduplicated these trampolines by signature. Now we compile two trampolines per
escaping function: one for if the host calls via the array calling convention
and one for it the host calls via the native calling convention. Additionally,
we compile a trampoline for every type in the module, in case there is a native
calling convention function from the host that we `call_indirect` of that
type. Much of this is in the `.eh_frame` section in the compiled module, because
each of our trampolines needs an entry there. Note that the `.eh_frame` section
is not required for Wasmtime's correctness, and you can disable its generation
to shrink compiled module code size; we just emit it to play nice with external
unwinders and profilers. We believe there are code size gains available for
follow up work to offset this code size regression in the future.
Backing up a bit: the reason each Wasm module needs to provide these
Wasm-to-native trampolines is because `wasmtime::Func::wrap` and friends allow
embedders to create functions even when there is no compiler available, so they
cannot bring their own trampoline. Instead the Wasm module has to supply
it. This in turn means that we need to look up and patch in these Wasm-to-native
trampolines during roughly instantiation time. But instantiation is super hot,
and we don't want to add more passes over imports or any extra work on this
path. So we integrate with `wasmtime::InstancePre` to patch these trampolines in
ahead of time.
Co-Authored-By: Jamey Sharp <jsharp@fastly.com>
Co-Authored-By: Alex Crichton <alex@alexcrichton.com>
prtest:full
* Fix miscompile from functions mutating `VMContext`
This commit fixes a miscompilation in Wasmtime on LLVM 16 where methods
on `Instance` which mutated the state of the internal `VMContext` were
optimized to not actually mutate the state. The root cause of this issue
is a change in LLVM which takes advantage of `noalias readonly` pointers
which is how `&self` methods are translated. This means that `Instance`
methods which take `&self` but actually mutate the `VMContext` end up
being undefined behavior from LLVM's point of view, meaning that the
writes are candidate for removal.
The fix applied here is intended to be a temporary one while a more
formal fix, ideally backed by `cargo miri` verification, is implemented
on `main`. The fix here is to change the return value of
`vmctx_plus_offset` to return `*const T` instead of `*mut T`. This
caused lots of portions of the runtime code to stop compiling because
mutations were indeed happening. To cover these a new
`vmctx_plus_offset_mut` method was added which notably takes `&mut self`
instead of `&self`. This forced all callers which may mutate to reflect
the `&mut self` requirement, propagating that outwards.
This fixes the miscompilation with LLVM 16 in the immediate future and
should be at least a meager line of defense against issues like this in
the future. This is not a long-term fix, though, since `cargo miri`
still does not like what's being done in `Instance` and with
`VMContext`. That fix is likely to be more invasive, though, so it's
being deferred to later.
* Update release notes
* Fix dates and fill out more notes
* tests: remove all use of rights for anything besides path_open read | write
* wasi-common and friends: delete all Caps from FileEntry and DirEntry
the sole thing rights are used to determine is whether a path_open
is opening for reading and writing.
It seems that this fell through given that the incremental cache is
behind a cargo feature. I noticed this while building
`cranelift-codegen` via `cargo build --all-features`.
I decided to add a check in CI to hopefully prevent this in the future,
but I'm happy to remove it / update it if there's a better way or another way.
Several of these badges were out of date, with some crates in wide production
use marked as "experimental". Insted of trying to keep them up to date, just
remove them, since they are [no longer displayed on crates.io].
[no longer displayed on crates.io]: https://doc.rust-lang.org/cargo/reference/manifest.html#the-badges-section
The `Config` needs to be mutable while building a compiler, but in a
build configuration without a compiler, declaring it as `mut` produces a
warning since nothing else needs that.
I found the existing workaround for this warning confusing, so this PR
removes `mut` from the binding for `config` and instead re-binds the
variable in builds where we call `build_compiler`.
* winch(fuzz): Initial support for differential fuzzing
This commit introduces initial support for differential fuzzing for Winch. In
order to fuzz winch, this change introduces the `winch` cargo feature. When the
`winch` cargo feature is enabled the differential fuzz target uses `wasmi` as
the differential engine and `wasm-smith` and `single-inst` as the module sources.
The intention behind this change is to have a *local* approach for fuzzing and
verifying programs generated by Winch and to have an initial implementation that
will allow us to eventually enable this change by default. Currently it's not
worth it to enable this change by default given all the filtering that needs to
happen to ensure that the generated modules are supported by Winch.
It's worth noting that the Wasm filtering code will be temporary, until Winch
reaches feature parity in terms of Wasm operators.
* Check build targets with the `winch` feature flag
* Rename fuzz target feature to `fuzz-winch`
This crate re-exports the `Backtrace` type at top-level from a nested
module. `Backtrace` in turn has `Frame` in its public API, which is not
re-exported anywhere. This is legal and external users can call methods
on `Frame`, but it doesn't appear in the rustdocs, making it
unnecessarily difficult to figure out how to use this API. Re-exporting
`Frame` fixes that, and also allows naming the type directly if needed.
Pat Hickey
Daniel Bevenius
Pat Hickey
theothergraham
Eduardo de Moura Rodrigues
Rainy Sinclair
Nick Fitzgerald
Alex Crichton
Juan Jose Medina
wasmtime-publish
Andrew Brown
Dante Broggi
Saúl Cabrera
Jamey Sharp
Trevor Elliott
Martin Evans
Dan Gohman