1218: Enable clif verifier in debug mode, fix issue with verifier r=MarkMcCaskey a=MarkMcCaskey
Ensures we're using I32s to index into things that are indexed by I32s
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Mark McCaskey <mark@wasmer.io>
1209: Maybe improve safety of MemoryView Deref r=MarkMcCaskey a=MarkMcCaskey
Possibly slightly better... (effectively does exactly the same thing the same way):
Notably this code still violates the safety rules of its unsafe functions:
It violates rule 2 from https://doc.rust-lang.org/std/slice/fn.from_raw_parts_mut.html :
> The memory referenced by the returned slice must not be accessed through any other pointer (not derived from the return value) for the duration of lifetime ’a. Both read and write accesses are forbidden.
Some comments in the stdlib indicate that casting between `Cell<T>` and `T` isn't something that's safe to do outside of the stdlib 🤷♂ .
Fundamentally, `MemoryView` is unsound. Our docs say that it does not have undefined behavior, but we don't properly justify that. I believe it relies very heavily on undefined behavior.
Looking for feedback here about what we can do. It seems like we'll have to break the public API to make a sound API... if we can decide on a sufficiently good one, we can deprecate the old one and roll out the new one to prevent user breakage.
We may need to use something like https://docs.rs/crossbeam/0.7.3/crossbeam/atomic/struct.AtomicCell.html or implement something like it.
Where I'm at in regards to memory access from the host is that it's not possible to make any kind of efficient API that is not entirely `unsafe`. Even given that, we need to figure out the bounds with which the `unsafe` functions can be used relatively safely. I think even if we marked our existing functions as `unsafe`, it's too complex to figure out whether or not you're using it correctly...
Bonus points if your solution works across multiple threads properly...
# Review
- [ ] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Mark McCaskey <mark@wasmer.io>
Co-authored-by: Mark McCaskey <5770194+MarkMcCaskey@users.noreply.github.com>
1214: test(interface-types) Add `wasmer-interface-types` to `make check` r=MarkMcCaskey a=Hywan
Sequel of #787. Forgot to update the changelog, and to add `wasmer-interface-types` to `make check`.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
Co-authored-by: Mark McCaskey <5770194+MarkMcCaskey@users.noreply.github.com>
1213: Fixed WASI isatty r=syrusakbary a=syrusakbary
<!--
Prior to submitting a PR, review the CONTRIBUTING.md document for recommendations on how to test:
https://github.com/wasmerio/wasmer/blob/master/CONTRIBUTING.md#pull-requests
-->
# Description
Current WASI implementation returns a wrong response when libc `isatty` is used for `stdin`, `stdout` or `stderr`.
This PR fixes it.
<!--
Provide details regarding the change including motivation,
links to related issues, and the context of the PR.
-->
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Syrus <me@syrusakbary.com>
Co-authored-by: Syrus Akbary <me@syrusakbary.com>
787: feat(interface-types) Implement Interface Types (WIT) r=Hywan a=Hywan
So far, this PR implements a new crate named `wasmer-interface-types`. The goal is to implement the WebAssembly Interface Types (WIT) proposal, https://github.com/WebAssembly/interface-types. Keep in mind the proposal is highly unstable and experimental.
The `wasmer-interface-types` is designed to be _runtime agnostic_, which means that there is no connection between this crate and `wasmer-runtime-core` or `wasmer-runtime` (or any backend crates). The hope is that other runtimes could use `wasmer-interface-types` according to their needs.
The `wasmer-interface-types` is composed of 4 parts:
* AST: [The WIT language, represented as an AST](https://github.com/Hywan/wasmer/blob/feat-interface-types/lib/interface-types/src/ast.rs) (it's not really abstract though),
* Decoders: So far, it contains only [one parser that reads the WIT binary language](https://github.com/Hywan/wasmer/blob/feat-interface-types/lib/interface-types/src/decoders/binary.rs) and produces an AST,
* Encoders: So far, it contains only [one compiler that transforms the AST into "WIT.wat”](https://github.com/Hywan/wasmer/blob/feat-interface-types/lib/interface-types/src/encoders/wat.rs), i.e. the textual representation of an Interface Types AST
* Instructions: WIT defines a new concept called Adapters. An adapter contains a set of instructions. Those instructions are executed when data are bound. So, in more details, this module contains:
* [`interpreter.rs`](https://github.com/Hywan/wasmer/blob/feat-interface-types/lib/interface-types/src/interpreter/mod.rs), a stack-based interpreter, defined by:
* A compiler that transforms a set of instructions into a set of _executable_ instructions,
* A stack,
* A runtime that holds the “invocation inputs” (arguments of the interpreter), the stack, and the Wasm instance (which holds the exports, the imports, the memories, the tables etc.),
* [`stack.rs`](https://github.com/Hywan/wasmer/blob/feat-interface-types/lib/interface-types/src/interpreter/stack.rs), a very light and generic stack implementation, exposing only the API required by the interpreter,
* [`wasm/*.rs`](https://github.com/Hywan/wasmer/blob/feat-interface-types/lib/interface-types/src/interpreter/wasm/structures.rs), a set of enums, types, and traits to represent a Wasm runtime —basically this is the part a runtime should take a look to support the `wasmer-interface-types` crate—.
Progression:
* [x] WIT binary parser,
* [x] WIT.wat compiler,
* [ ] Interpreter:
* [ ] Wasm runtime traits to represent:
* [x] Instance,
* [x] Export,
* [x] Memory,
* [x] Import,
* [ ] Table,
* [x] Generic stack implementation,
* [ ] Implemented instructions:
* [x] `arg.get`,
* [x] `call`,
* [x] `call-export`,
* [x] `read-utf8`,
* [x] `write-utf8`,
* [ ] `as-wasm`,
* [ ] `as-interface`
* [ ] `table-ref-add`
* [ ] `table-ref-get`
* [ ] `call-method`
* [ ] `make-record`
* [ ] `get-field`
* [ ] `const`
* [ ] `fold-seq`
* [ ] `add`
* [ ] `mem-to-seq`
* [ ] `load`
* [ ] `seq.new`
* [ ] `list.push`
* [ ] `repeat-until`
* [ ] `seq-to-mem`
* [ ] `store`
* [ ] Plug `wasmer-interface-types` into `wasmer-runtime-core`
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
The LEB parser is renamed `uleb`. It now checks for overflow, and
badly-formed bits, resp. `TooLarge` or `Eof`. More test cases are
added, whose from the DWARF 4 standard.
As @MarkMcCaskey noted, `Type` can be corrupted because `field_names`
and `field_types` must have the same length. This patch removes the
public visibility, and adds methods like `new`, `add_field`,
`field_names` and `field_types` to encapsulate `Type` internal data.
1208: Fix trap handling bug on Windows and add test r=MarkMcCaskey a=MarkMcCaskey
Resolves#1204
# Review
- [ ] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Mark McCaskey <mark@wasmer.io>
1191: Fix singlepass miscompilation on `Operator::CallIndirect`. r=losfair a=losfair
This fixes the 3 failing tests mentioned in https://00f.net/2019/10/22/updated-webassembly-benchmark/ .
(TODO: Add test cases?)
Co-authored-by: losfair <zhy20000919@hotmail.com>
1207: Update Rust version used to build docs to be consistent r=syrusakbary a=MarkMcCaskey
In response to #1196
Co-authored-by: Mark McCaskey <mark@wasmer.io>
1192: Use `ExceptionCode` for error representation. r=losfair a=losfair
Extends https://github.com/wasmerio/wasmer/pull/1129 to all backends.
Co-authored-by: losfair <zhy20000919@hotmail.com>
