Fix panicking overflow when calculating table sizes (#13244)Return an error instead of panicking in the same manner that OOM ishandled.
winch: Fix `memory.atomic.*` with overflowing offsets (#12909)* winch: Fix `memory.atomic.*` with overflowing offsetsThis commit fixes a spec-compliance issue with `memory.atomic.*`instructions
winch: Fix `memory.atomic.*` with overflowing offsets (#12909)* winch: Fix `memory.atomic.*` with overflowing offsetsThis commit fixes a spec-compliance issue with `memory.atomic.*`instructions using the Winch compiler. Specifically Winch previouslyadded the dynamic offset to the static offset when calculating theeffective address of the operation, but this addition was allowed tooverflow. This meant that an operation which should trap would continueinstead. The fix here is to use checked arithmetic at runtime to ensurethat the address computation does not overflow.* Update test expectations
show more ...
Fix table64 initialization when bulk memory is disabled (#12894)* Fix table64 initialization when bulk memory is disabledThis commit fixes a panic in the host during instantiation when the`bulk_
Fix table64 initialization when bulk memory is disabled (#12894)* Fix table64 initialization when bulk memory is disabledThis commit fixes a panic in the host during instantiation when the`bulk_memory` wasm feature is disabled. In this mode the initializationof tables/memories is slightly different and a refactoring for 64-bitsupport wasn't applied to this code path, meaning that it resulted in apanic instead of properly handling 64-bit tables.* Fix clippy
Add `bulk_memory` to wast configuration (#12883)Allows enabling/disabling this wasm proposal on a per-test basis.
Refactor the `#[wasmtime_test]` macro (#9627)* Refactor the `#[wasmtime_test]` macro* Start tests with a blank slate of features instead of with the default set of features enables (ensures eac
Refactor the `#[wasmtime_test]` macro (#9627)* Refactor the `#[wasmtime_test]` macro* Start tests with a blank slate of features instead of with the default set of features enables (ensures each test explicitly specifies required features)* Reuse test features from `wasmtime_wast_util` to avoid duplicating listings of features. Also shares logic for "should this compiler fail this test because of unsupported features".* Move logic in `tests/wast.rs` to apply test configuration to a `Config` to a new location that can be shared across suites.* Add a new feature for `simd` and flag tests that need it with the feature.This is done in preparation for adding a new compiler strategy of Pulleyto be able to flag tests as passing for pulley or not.* Review feedback
Improve fuzzing of `*.wast` tests (#9587)* Improve fuzzing of `*.wast` testsCurrently we have a fuzzer which is tasked with running `*.wast` testswith fuzz-generated configurations. This asserts
Improve fuzzing of `*.wast` tests (#9587)* Improve fuzzing of `*.wast` testsCurrently we have a fuzzer which is tasked with running `*.wast` testswith fuzz-generated configurations. This asserts that we at leastsatisfy all basic wasm semantics regardless of how various knobs in`Config` are turned (modulo limits to resources). The current fuzzingthough is not comprehensive in that it doesn't include all the spectests that we pass from all proposals. This runs the risk of we don'tactually fuzz anything until the spec tests are merged upstream, whichcan take a significant amount of time.This commit refactors the `*.wast`-management infrastructure to sharetest discovery and feature calculation between `tests/wast.rs` andfuzzing. This new support crate centralizes limits and discovery forboth to use. Additionally fuzzing is updated to no longer throw out testcases if configuration isn't applicable but instead clamp configurationto the minimum required values (e.g. features + resource limits). Thismeans that we should now be fuzzing all spec tests that pass in allconfigurations.This new fuzzer discovered a few minor issues with the GC proposalimplementation, for example, such as:* Some instructions were translated using trapping methods directly on `FunctionBuilder` rather than `FuncEnvironment` meaning they didn't properly handle `signals-based-traps` configuration.* Fuel handling for `return_call_ref` wasn't correct because it was accidentally omitted from the list of return-call instructions that need special treatment.* Add some manifest metadata
Refactor how wasm features are calculated for `*.wast` tests (#9560)* Refactor how wasm features are calculated for `*.wast` testsThis commit refactors the `tests/wast.rs` test suite which runs a
Refactor how wasm features are calculated for `*.wast` tests (#9560)* Refactor how wasm features are calculated for `*.wast` testsThis commit refactors the `tests/wast.rs` test suite which runs all ofthe upstream spec tests as `*.wast` files as well as our own`misc_testsuite` which has its own suite of `*.wast` files. Previouslythe set of wasm features active for each test was a sort of randommishmash and convoluted set of conditionals which was updated and editedover time as upstream proposal test suites evolved. This was thenmirrored into our own conventions for `misc_testsuite` as well. Overallthough this has a number of downsides I'm trying to fix here:* The calculation of what features are enabled is quite complicated and effectively a random mishmash of `||` conditionals with hierarchies that don't make any sense beyond "this is just required to get things to pass".* There is no means of per-test configuration. For example `canonicalize-nans.wast` had hardcoded logic in `tests/wast.rs` that it needed a different setting turned on in `Config`.* There was no easy means to write tests for Wasmtime which take a union of a number of proposals together without having lots of sub-folders that may not make sense.* Tests that require a particular proposal had to have duplicate logic for Winch as it doesn't support the full suite of features of all proposals that Cranelift does.The new system implemented in this commit takes a leaf out of the`disas` tests. There is a new `TestConfig` structure in the`tests/wast.rs` harness which is decoded from each test (leading `;;!`comments) which enables specifying, in each test, what's required. Thisencompasses many wasm proposals but additionally captures other behaviorlike nan-canonicalization. This means that all test files in`misc_testsuite/**/*.wast` are now manually annotated with what wasmfeatures they require and what's needed to run. This makes per-testconfiguration much easier, per-config-setting much easier, and blanketignore-by-proposal for Winch much easier as well.For spec tests we can't modify the contents of the upstream `*.wast`files. To handle this they're handled specially where `TestConfig` ismanually created and manipulated for each spec proposal and the maintest suite itself. This enables per-proposal configuration that doesn'tleak into any others and makes it more obvious what proposals are doingwhat.* Hack around Winch support for aarch64
Improve linking-related error messages (#3353)Include more contextual information about why the link failed related to why the types didn't match. Closes #3172
Implement a setting for reserved dynamic memory growth (#3215)* Implement a setting for reserved dynamic memory growth Dynamic memories aren't really that heavily used in Wasmtime right now bec
Implement a setting for reserved dynamic memory growth (#3215)* Implement a setting for reserved dynamic memory growth Dynamic memories aren't really that heavily used in Wasmtime right now because for most 32-bit memories they're classified as "static" which means they reserve 4gb of address space and never move. Growth of a static memory is simply making pages accessible, so it's quite fast. With the memory64 feature, however, this is no longer true since all memory64 memories are classified as "dynamic" at this time. Previous to this commit growth of a dynamic memory unconditionally moved the entire linear memory in the host's address space, always resulting in a new `Mmap` allocation. This behavior is causing fuzzers to time out when working with 64-bit memories because incrementally growing a memory by 1 page at a time can incur a quadratic time complexity as bytes are constantly moved. This commit implements a scheme where there is now a tunable setting for memory to be reserved at the end of a dynamic memory to grow into. This means that dynamic memory growth is ideally amortized as most calls to `memory.grow` will be able to grow into the pre-reserved space. Some calls, though, will still need to copy the memory around. This helps enable a commented out test for 64-bit memories now that it's fast enough to run in debug mode. This is because the growth of memory in the test no longer needs to copy 4gb of zeros. * Test fixes & review comments * More comments
Implement the memory64 proposal in Wasmtime (#3153)* Implement the memory64 proposal in Wasmtime This commit implements the WebAssembly [memory64 proposal][proposal] in both Wasmtime and Cranel
Implement the memory64 proposal in Wasmtime (#3153)* Implement the memory64 proposal in Wasmtime This commit implements the WebAssembly [memory64 proposal][proposal] in both Wasmtime and Cranelift. In terms of work done Cranelift ended up needing very little work here since most of it was already prepared for 64-bit memories at one point or another. Most of the work in Wasmtime is largely refactoring, changing a bunch of `u32` values to something else. A number of internal and public interfaces are changing as a result of this commit, for example: * Acessors on `wasmtime::Memory` that work with pages now all return `u64` unconditionally rather than `u32`. This makes it possible to accommodate 64-bit memories with this API, but we may also want to consider `usize` here at some point since the host can't grow past `usize`-limited pages anyway. * The `wasmtime::Limits` structure is removed in favor of minimum/maximum methods on table/memory types. * Many libcall intrinsics called by jit code now unconditionally take `u64` arguments instead of `u32`. Return values are `usize`, however, since the return value, if successful, is always bounded by host memory while arguments can come from any guest. * The `heap_addr` clif instruction now takes a 64-bit offset argument instead of a 32-bit one. It turns out that the legalization of `heap_addr` already worked with 64-bit offsets, so this change was fairly trivial to make. * The runtime implementation of mmap-based linear memories has changed to largely work in `usize` quantities in its API and in bytes instead of pages. This simplifies various aspects and reflects that mmap-memories are always bound by `usize` since that's what the host is using to address things, and additionally most calculations care about bytes rather than pages except for the very edge where we're going to/from wasm. Overall I've tried to minimize the amount of `as` casts as possible, using checked `try_from` and checked arithemtic with either error handling or explicit `unwrap()` calls to tell us about bugs in the future. Most locations have relatively obvious things to do with various implications on various hosts, and I think they should all be roughly of the right shape but time will tell. I mostly relied on the compiler complaining that various types weren't aligned to figure out type-casting, and I manually audited some of the more obvious locations. I suspect we have a number of hidden locations that will panic on 32-bit hosts if 64-bit modules try to run there, but otherwise I think we should be generally ok (famous last words). In any case I wouldn't want to enable this by default naturally until we've fuzzed it for some time. In terms of the actual underlying implementation, no one should expect memory64 to be all that fast. Right now it's implemented with "dynamic" heaps which have a few consequences: * All memory accesses are bounds-checked. I'm not sure how aggressively Cranelift tries to optimize out bounds checks, but I suspect not a ton since we haven't stressed this much historically. * Heaps are always precisely sized. This means that every call to `memory.grow` will incur a `memcpy` of memory from the old heap to the new. We probably want to at least look into `mremap` on Linux and otherwise try to implement schemes where dynamic heaps have some reserved pages to grow into to help amortize the cost of `memory.grow`. The memory64 spec test suite is scheduled to now run on CI, but as with all the other spec test suites it's really not all that comprehensive. I've tried adding more tests for basic things as I've had to implement guards for them, but I wouldn't really consider the testing adequate from just this PR itself. I did try to take care in one test to actually allocate a 4gb+ heap and then avoid running that in the pooling allocator or in emulation because otherwise that may fail or take excessively long. [proposal]: https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md * Fix some tests * More test fixes * Fix wasmtime tests * Fix doctests * Revert to 32-bit immediate offsets in `heap_addr` This commit updates the generation of addresses in wasm code to always use 32-bit offsets for `heap_addr`, and if the calculated offset is bigger than 32-bits we emit a manual add with an overflow check. * Disable memory64 for spectest fuzzing * Fix wrong offset being added to heap addr * More comments! * Clarify bytes/pages