With `Module::{serialize,deserialize}` it should be possible to share
wasmtime modules across machines or CPUs. Serialization, however, embeds
a hash of all configuration values, including cranelift compilation
settings. By default wasmtime's selection of the native ISA would enable
ISA flags according to CPU features available on the host, but the same
CPU features may not be available across two machines.
This commit adds a `Config::cranelift_clear_cpu_flags` method which
allows clearing the target-specific ISA flags that are automatically
inferred by default for the native CPU. Options can then be
incrementally built back up as-desired with teh `cranelift_other_flag`
method.
change reopen_with_fdflags(&self, fdflags) -> Result<Box<dyn WasiFile>>
to set_fdflags(&mut self, fdflags) -> Result<()>.
this makes way more sense than my prior hare-brained schemes.
This commit introduces two new methods on `Memory` that enable
reading and writing memory contents without requiring `unsafe`.
The methods return a new `MemoryError` if the memory access
fails.
* need to close the handle to the subdirectory before its legal to
delete it
* windows doesnt give us a way to distinguish between an ERRNO_PERM and
an ERRNO_ACCES, so lets accept either one
* path_open of a directory without OFLAGS_DIRECTORY worked on linux,
but fortunately not on windows!
* the errno is BADF instead of NOTCAPABLE for fd_seek on a directory
* no way for a directory to have the FD_SEEK right.
cargo-deny tells us that we should upgrade raw-cpuid to v9.0.0. This
new version also seems to lack the `nightly` feature (perhaps it has
been incorporated into the base functionality) so I had to remove this
feature selector to build.
* Add support for the experimental wasi-crypto APIs
The sole purpose of the implementation is to allow bindings and
application developers to test the proposed APIs.
Rust and AssemblyScript bindings are also available as examples.
Like `wasi-nn`, it is currently disabled by default, and requires
the `wasi-crypto` feature flag to be compiled in.
* Rename the wasi-crypto/spec submodule
* Add a path dependency into the submodule for wasi-crypto
* Tell the publish script to vendor wasi-crypto
I had missed that the CI config didn't actually run the tests, because
(I think) `matrix.target` is not set by default (?). All of our hosts
are native x86-64, so we can just gate on OS (Ubuntu) instead.
I also discovered that while I had been testing with the gdb tests
locally, when *all* `debug::*` tests are run, there are two that do not
pass on the new backend because of specific differences in compiled
code. One is a value-lifetime issue (the value is "optimized out" at the
point the breakpoint is set) and the other has to do with basic-block
order (it is trying to match against hardcoded machine-code offsets
which have changed).
