Changes:
* uses Rust edition 2018
* returns wasm32 errno directly rather than relying on
wasi_common::{host, memory} modules
* wraps extraction of memory and WASI context in a macro
* Workaround a rounding difference in the strtof function in Centos 6.
This difference causes the spec test const.wast to fail, so disable the
test on platforms where we detect the rounding difference occurs.
This commit adds a `wasmtime-rust` crate to the `misc` folder next to
the previously added Python extension. The intention is that this
showcases loading a WebAssembly file natively in Rust and how with an
attribute macro it can feel lightweight in terms of boilerplate.
The macro itself is pretty non-featureful today beyond the bare bones to
get anything working, but there's all sorts of possibilities like
JIT-compiled entry stubs we could eventually do with all the type
information!
This commit adds initial support for [WebAssembly Interface
Types][proposal] to wasmtime. This is all intended to be quite
experimental, so experimental in fact that even the name of the
[proposal] is still in flux. (this has otherwise been known as "host
bindings" or "webidl bindings" or "wasm bindings").
The goal of this commit is to start adding support the wasmtime set of
crates for WebAssembly Interface Types. A new `wasmtime-interface-types`
crate has been added with very basic support for dynamically invoking
and inspecting the various bindings of a module. This is in turn powered
by the `wasm-webidl-bindings` crate which is shared with the
`wasm-bindgen` CLI tool as a producer of this section.
Currently the only integration in `wasmtime`-the-binary itself is that
when passed the `--invoke` argument the CLI will now attempt to invoke
the target function with arguments as parsed from the command line
itself. For example if you export a function like:
fn render(&str) -> String
Then passing `--invoke render` will require one argument on the command
line, which is the first argument as a string, and the return value is
printed to the console. This differs from today's interpretation of
`--invoke` where it is a failure if the invoked function takes more than
one argument and the return values are currently ignored.
This is intended to also be the basis of embedding wasmtime in other
contexts which also want to consume WebAssembly interface types. A
Python extension is also added to this repository which implements the
`wasmtime` package on PyPI. This Python extension is intended to make it
as easy as `pip3 install wasmtime` to load a WebAssembly file with
WebAssembly Interface Types into Python. Extensions for other languages
is of course possible as well!
One of the major missing pieces from this is handling imported functions
with interface bindings. Currently the embedding support doesn't have
much ability to support handling imports ergonomically, so it's intended
that this will be included in a follow-up patch.
[proposal]: https://github.com/webassembly/webidl-bindings
Co-authored-by: Yury Delendik <ydelendik@mozilla.com>
Move `src/*.rs` to `src/bin/*.rs` which are automatically inferred as
binaries and move `src/utils.rs` to `src/lib.rs` which is compiled as a
reusable library for each of the binaries we're building.
Currently our Linux binaries aren't quite as portable as they otherwise could
be. There's two primary reasons for this, and one of them is that the binary is
produced in a relatively recent Linux distribution (Ubuntu 16.04) which means
it has a relatively recent requirement in terms of glibc versions. On
OSX/Windows we can set some flags to rely on older libc implementations, but on
Linux we have to actually build against an older version.
This commit switches the container for the build to CentOS 6 instead of the
default Ubuntu 16.04. The main trick here is also finding a C++11-capable
compiler to compile wabt. Turns out though there's a helpful tutorial for this
at https://edwards.sdsu.edu/research/c11-on-centos-6/ and it was as easy as
installing a few packages.
The second portability concern of our Linux binaries is that they link
dynamically to `libstdc++.so` which isn't always installed on target systems,
or even if it is it may be too old or have a different ABI. This is solved by
statically linking to `libstdc++.a` in the build on Azure by doing a bit of
trickery with libraries and what's available.
After these results the glibc requirements drops from 2.18 (released in 2013)
to 2.6 (released in 2007) and avoids the need for users to have libstdc++.so
installed. We may eventually want to investigate fully-static musl binaries,
but finding a musl compiler for C++ is something I'm not that good at, so I
figure this is probably good enough for now.
* Remove cmake/bindgen/llvm from wasmtime-runtime
This commit removes the cmake/bindgen dependency (which removes the need
for `llvm-config`) from the `wasmtime-runtime` crate. The C++ code is
instead compiled with the `cc` crate (it's just one file anyway) and the
interface is handwritten since it's quite small anyway.
Some other changes are:
* The `TrapContext` type in C++ was removed since it was unused, and it
was moved to Rust with a `Cell` on each field.
* Functions between Rust/C++ now return `int` instead of `bool` to make
them a bit more FFI compatible portably.
* The `jmp_buf` type has a workaround that will be fixed in the next commit.
* Move setjmp/longjmp to C++
This commit moves the definition of setjmp and longjmp into C++. This is
primarily done because it's [debatable whether it's possible to call
`setjmp` from Rust][rfc]. The semantics of `setjmp` are that it returns
twice but LLVM doesn't actually know about this because rustc isn't
telling LLVM this information, so it's unclear whether it can ever be
safe.
Additionally this removes the need for Rust code to know the definition
of `jmp_buf` which is a pretty hairy type to define in Rust across
platforms.
The solution in this commit is to move all setjmp/longjmp code to C++,
and that way we should be able to guarantee that jumps over wasm JIT
code should always go from C++ to C++, removing Rust from the equation
for now from needing to get any fiddly bits working across platforms.
This should overall help it be a bit more portable and also means Rust
doesn't have to know about `jmp_buf` as a type.
The previous `Vec` of `jmp_buf` is now replaced with one thread-local
pointer where previous values are stored on the stack and restored when
the function returns. This is intended to be functionally the same as
the previous implementation.
[rfc]: https://github.com/rust-lang/rfcs/issues/2625
* rustfmt
* Use volatile loads/stores
* Remove mention of cmake from README
While the "__wasi_memory" name is something we considered, the name
currently being used for the memory exported to WASI is "memory", so
adjust the error message accordingly.
* Simple module compilation cache
* Fix base64 encoding bug
* Use warn! everywhere in cache system
* Remove unused import
* Temporary workaround for long path on Windows
* Remove unused import for non-windows builds
* Add command line argument to enable cache system + apply minor review feedback
* Initial implementation of partial module hashing
* Proper module hashing for the cache
* Use newer version of cranelift
