|
|
|
//! Build program to generate a program which runs all the testsuites.
|
|
|
|
//!
|
|
|
|
//! By generating a separate `#[test]` test for each file, we allow cargo test
|
|
|
|
//! to automatically run the files in parallel.
|
|
|
|
|
|
|
|
use anyhow::Context;
|
|
|
|
use std::env;
|
|
|
|
use std::fmt::Write;
|
|
|
|
use std::fs;
|
|
|
|
use std::path::{Path, PathBuf};
|
|
|
|
use std::process::Command;
|
|
|
|
|
|
|
|
fn main() -> anyhow::Result<()> {
|
|
|
|
println!("cargo:rerun-if-changed=build.rs");
|
|
|
|
let out_dir = PathBuf::from(
|
|
|
|
env::var_os("OUT_DIR").expect("The OUT_DIR environment variable must be set"),
|
|
|
|
);
|
|
|
|
let mut out = String::new();
|
|
|
|
|
|
|
|
for strategy in &["Cranelift"] {
|
|
|
|
writeln!(out, "#[cfg(test)]")?;
|
|
|
|
writeln!(out, "#[allow(non_snake_case)]")?;
|
|
|
|
writeln!(out, "mod {} {{", strategy)?;
|
|
|
|
|
|
|
|
with_test_module(&mut out, "misc", |out| {
|
|
|
|
test_directory(out, "tests/misc_testsuite", strategy)?;
|
|
|
|
test_directory_module(out, "tests/misc_testsuite/multi-memory", strategy)?;
|
|
|
|
test_directory_module(out, "tests/misc_testsuite/simd", strategy)?;
|
|
|
|
test_directory_module(out, "tests/misc_testsuite/threads", strategy)?;
|
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
3 years ago
|
|
|
test_directory_module(out, "tests/misc_testsuite/memory64", strategy)?;
|
|
|
|
Ok(())
|
|
|
|
})?;
|
|
|
|
|
|
|
|
with_test_module(&mut out, "spec", |out| {
|
|
|
|
let spec_tests = test_directory(out, "tests/spec_testsuite", strategy)?;
|
|
|
|
// Skip running spec_testsuite tests if the submodule isn't checked
|
|
|
|
// out.
|
|
|
|
if spec_tests > 0 {
|
|
|
|
test_directory_module(out, "tests/spec_testsuite/proposals/simd", strategy)?;
|
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
3 years ago
|
|
|
test_directory_module(out, "tests/spec_testsuite/proposals/memory64", strategy)?;
|
|
|
|
} else {
|
|
|
|
println!(
|
|
|
|
"cargo:warning=The spec testsuite is disabled. To enable, run `git submodule \
|
|
|
|
update --remote`."
|
|
|
|
);
|
|
|
|
}
|
|
|
|
Ok(())
|
|
|
|
})?;
|
|
|
|
|
|
|
|
writeln!(out, "}}")?;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Write out our auto-generated tests and opportunistically format them with
|
|
|
|
// `rustfmt` if it's installed.
|
|
|
|
let output = out_dir.join("wast_testsuite_tests.rs");
|
|
|
|
fs::write(&output, out)?;
|
|
|
|
drop(Command::new("rustfmt").arg(&output).status());
|
|
|
|
Ok(())
|
|
|
|
}
|
|
|
|
|
|
|
|
fn test_directory_module(
|
|
|
|
out: &mut String,
|
|
|
|
path: impl AsRef<Path>,
|
|
|
|
strategy: &str,
|
|
|
|
) -> anyhow::Result<usize> {
|
|
|
|
let path = path.as_ref();
|
|
|
|
let testsuite = &extract_name(path);
|
|
|
|
with_test_module(out, testsuite, |out| test_directory(out, path, strategy))
|
|
|
|
}
|
|
|
|
|
|
|
|
fn test_directory(
|
|
|
|
out: &mut String,
|
|
|
|
path: impl AsRef<Path>,
|
|
|
|
strategy: &str,
|
|
|
|
) -> anyhow::Result<usize> {
|
|
|
|
let path = path.as_ref();
|
|
|
|
let mut dir_entries: Vec<_> = path
|
|
|
|
.read_dir()
|
|
|
|
.context(format!("failed to read {:?}", path))?
|
|
|
|
.map(|r| r.expect("reading testsuite directory entry"))
|
|
|
|
.filter_map(|dir_entry| {
|
|
|
|
let p = dir_entry.path();
|
|
|
|
let ext = p.extension()?;
|
|
|
|
// Only look at wast files.
|
|
|
|
if ext != "wast" {
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
// Ignore files starting with `.`, which could be editor temporary files
|
|
|
|
if p.file_stem()?.to_str()?.starts_with(".") {
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
Some(p)
|
|
|
|
})
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
dir_entries.sort();
|
|
|
|
|
|
|
|
let testsuite = &extract_name(path);
|
|
|
|
for entry in dir_entries.iter() {
|
|
|
|
write_testsuite_tests(out, entry, testsuite, strategy, false)?;
|
|
|
|
write_testsuite_tests(out, entry, testsuite, strategy, true)?;
|
|
|
|
}
|
|
|
|
|
|
|
|
Ok(dir_entries.len())
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Extract a valid Rust identifier from the stem of a path.
|
|
|
|
fn extract_name(path: impl AsRef<Path>) -> String {
|
|
|
|
path.as_ref()
|
|
|
|
.file_stem()
|
|
|
|
.expect("filename should have a stem")
|
|
|
|
.to_str()
|
|
|
|
.expect("filename should be representable as a string")
|
|
|
|
.replace("-", "_")
|
|
|
|
.replace("/", "_")
|
|
|
|
}
|
|
|
|
|
|
|
|
fn with_test_module<T>(
|
|
|
|
out: &mut String,
|
|
|
|
testsuite: &str,
|
|
|
|
f: impl FnOnce(&mut String) -> anyhow::Result<T>,
|
|
|
|
) -> anyhow::Result<T> {
|
|
|
|
out.push_str("mod ");
|
|
|
|
out.push_str(testsuite);
|
|
|
|
out.push_str(" {\n");
|
|
|
|
|
|
|
|
let result = f(out)?;
|
|
|
|
|
|
|
|
out.push_str("}\n");
|
|
|
|
Ok(result)
|
|
|
|
}
|
|
|
|
|
|
|
|
fn write_testsuite_tests(
|
|
|
|
out: &mut String,
|
|
|
|
path: impl AsRef<Path>,
|
|
|
|
testsuite: &str,
|
|
|
|
strategy: &str,
|
|
|
|
pooling: bool,
|
|
|
|
) -> anyhow::Result<()> {
|
|
|
|
let path = path.as_ref();
|
|
|
|
let testname = extract_name(path);
|
|
|
|
|
|
|
|
writeln!(out, "#[test]")?;
|
|
|
|
// Ignore when using QEMU for running tests (limited memory).
|
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
3 years ago
|
|
|
if ignore(testsuite, &testname, strategy) {
|
|
|
|
writeln!(out, "#[ignore]")?;
|
|
|
|
}
|
|
|
|
|
|
|
|
writeln!(
|
|
|
|
out,
|
|
|
|
"fn r#{}{}() {{",
|
|
|
|
&testname,
|
|
|
|
if pooling { "_pooling" } else { "" }
|
|
|
|
)?;
|
|
|
|
writeln!(out, " let _ = env_logger::try_init();")?;
|
|
|
|
writeln!(
|
|
|
|
out,
|
|
|
|
" crate::wast::run_wast(r#\"{}\"#, crate::wast::Strategy::{}, {}).unwrap();",
|
|
|
|
path.display(),
|
|
|
|
strategy,
|
|
|
|
pooling
|
|
|
|
)?;
|
|
|
|
writeln!(out, "}}")?;
|
|
|
|
writeln!(out)?;
|
|
|
|
Ok(())
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Ignore tests that aren't supported yet.
|
|
|
|
fn ignore(testsuite: &str, testname: &str, strategy: &str) -> bool {
|
|
|
|
match strategy {
|
|
|
|
"Cranelift" => match (testsuite, testname) {
|
|
|
|
// No simd support yet for s390x.
|
|
|
|
("simd", _) if platform_is_s390x() => return true,
|
|
|
|
("memory64", "simd") if platform_is_s390x() => return true,
|
|
|
|
_ => {}
|
|
|
|
},
|
|
|
|
_ => panic!("unrecognized strategy"),
|
|
|
|
}
|
|
|
|
|
|
|
|
false
|
|
|
|
}
|
|
|
|
|
|
|
|
fn platform_is_s390x() -> bool {
|
|
|
|
env::var("CARGO_CFG_TARGET_ARCH").unwrap() == "s390x"
|
|
|
|
}
|