Commit Graph

1785 Commits

Author SHA1 Message Date
Pat Hickey
9e04c5333c poll oneoff tests: what if we read a non-empty file? 2021-05-05 13:08:33 -07:00
Pat Hickey
3e8ea090c6 ci debugging 2021-05-05 11:24:27 -07:00
Pat Hickey
0faf3b248e wasmtime-wasi: keep exporting sync at the top level 2021-05-05 11:00:59 -07:00
Pat Hickey
e0f3423161 support windows 2021-05-04 14:28:45 -07:00
Pat Hickey
f76fe8b764 rewrite wasi-tokio as just an task::block_in_place wrapper on cap-std-sync 2021-05-04 14:15:50 -07:00
Pat Hickey
686d8c22f9 fix test harness 2021-05-04 11:18:20 -07:00
bjorn3
84c79982e7 Remove unnecessary dependencies
Found using cargo-udeps
2021-05-04 13:51:26 +02:00
Pat Hickey
5ab8346a05 fix windows sync scheduler 2021-05-03 12:23:24 -07:00
Pat Hickey
3df9cddf10 better unit test 2021-05-03 11:59:30 -07:00
Benjamin Bouvier
8811246a9f debug: Avoid underflow when scanning for landing pad bytes (#2866) 2021-05-03 11:58:40 -05:00
Ulrich Weigand
dfb1bc4d02 Trap handler changes to support s390x (#2871)
On s390x, SIGILL and SIGFPE are delivered with the PSW address
pointing *after* the faulting instruction, while SIGSEGV and
SIGBUS are delivered with the PSW address pointing *to* the
faulting instruction.  In order to support this, the common
code trap handler has to distinguish between those cases.

Also, enable SIGFPE on s390x (just like on x86).
2021-05-03 11:56:18 -05:00
Ulrich Weigand
e1cc1a67d5 Object file support for s390x (#2872)
Add support for s390x binary format object files.  In particular,
add support for s390x ELF relocation types (currently only
S390xPCRel32Dbl).
2021-05-03 11:50:00 -05:00
Ulrich Weigand
7a3791f9e9 Fiber support for s390x (#2870)
Add fiber support for the s390x architecture.
2021-05-03 11:01:10 -05:00
Pat Hickey
62c4f0d1f7 wasi-tokio kinda sorta working 2021-05-01 15:39:09 -07:00
Pat Hickey
7f34ccb909 various fixes to the design of Poll 2021-04-30 15:38:18 -07:00
Pat Hickey
b7efcbe80f jump through enough hoops for the poll lifetime to work out
you program rust for a few years and you think you're done tearing your
hair out over lifetimes, well, you'll find yourself wrong
2021-04-29 16:50:22 -07:00
Pat Hickey
ab4f5bb674 move dummy executor out to wiggle:: for reuse 2021-04-29 16:26:50 -07:00
Andrew Brown
92e0b6b9e8 wasi-nn: turn it on by default (#2859)
* wasi-nn: turn it on by default

This change makes the wasi-nn Cargo feature a default feature. Previously, a wasi-nn user would have to build a separate Wasmtime binary (e.g. `cargo build --features wasi-nn ...`) to use wasi-nn and the resulting binary would require OpenVINO shared libraries to be present in the environment in order to run (otherwise it would fail immediately with linking errors). With recent changes to the `openvino` crate, the wasi-nn implementation can defer the loading of the OpenVINO shared libraries until runtime (i.e., when the user Wasm program calls `wasi_ephemeral_nn::load`) and display a user-level error if anything goes wrong (e.g., the OpenVINO libraries are not present on the system). This runtime-linking addition allows the wasi-nn feature to be turned on by default and shipped with upcoming releases of Wasmtime. This change should be transparent for users who do not use wasi-nn: the `openvino` crate is small and the newly-available wasi-nn imports only affect programs in which they are used.

For those interested in reviewing the runtime linking approach added to the `openvino` crate, see https://github.com/intel/openvino-rs/pull/19.

* wasi-nn spec path: don't use canonicalize

* Allow dependencies using the ISC license

The ISC license should be [just as permissive](https://choosealicense.com/licenses/isc) as MIT, e.g., with no additional limitations.

* Add a `--wasi-modules` flag

This flag controls which WASI modules are made available to the Wasm program. This initial commit enables `wasi-common` by default (equivalent to `--wasi-modules=all`) and allows `wasi-nn` and `wasi-crypto` to be added in either individually (e.g., `--wasi-modules=wasi-nn`) or as a group (e.g., `--wasi-modules=all-experimental`).

* wasi-crypto: fix unused dependency

Co-authored-by: Pat Hickey <pat@moreproductive.org>
2021-04-29 15:03:28 -05:00
Pat Hickey
b3e1ab4553 restructure Poll to hold a Table and fd instead of a RefMut<dyn WasiFile>
unfortunately, the borrow checker defeated me: changing the
RwSubscription file form a Ref to a RefMut turned into borrow checker
errors in the impl of the poll_oneoff trait method.

This implementation makes an end run by having Poll hold onto the table
and fd, and borrow the file at the site of use, rather than try to own
the RefMut. I have no idea why this convinces the borrow checker that
anything is different, but it does and I need to get this PR done and
I don't think comprimising on this internal abstraction is worth
fighting against
2021-04-28 11:56:48 -07:00
Alex Crichton
7ec073cef1 Bring back per-thread lazy initialization (#2863)
* Bring back per-thread lazy initialization

Platforms Wasmtime supports may have per-thread initialization that
needs to run before WebAssembly. For example Unix needs to setup a
sigaltstack and macOS needs to set up mach ports. In #2757 this
per-thread setup was moved out of the invocation of a wasm function,
relying on the lack of Send for Store to initialize the thread at Store
creation time and never worry about it later.

This conflicted with [wasmtime's desired multithreading
story](https://github.com/bytecodealliance/wasmtime/pull/2812) so a new
[`Store::notify_switched_thread` was
added](https://github.com/bytecodealliance/wasmtime/pull/2822) to
explicitly indicate a Store has moved to another thread (if it unsafely
did so).

It turns out though that it's not always easy to determine when a
`Store` moves to a new thread. For example the Go bindings for Wasmtime
are generally unaware when a goroutine switches OS threads. This led to
https://github.com/bytecodealliance/wasmtime-go/issues/74 where a SIGILL
was left uncaught, making it appear that traps aren't working properly.

This commit revisits the decision in #2757 and moves per-thread
initialization back into the path of calling into WebAssembly. This is
differently from before, though, where there's still only one TLS access
on the path of calling into WebAssembly, unlike before where it was a
separate access. This allows us to get the speed benefits of #2757 as
well as the flexibility benefits of not having to explicitly move a
store between threads.

With this new ability this commit deletes the recently added
`Store::notify_switched_thread` method since it's no longer necessary.

* Fix a test compiling
2021-04-28 12:08:27 -05:00
Pat Hickey
02581ddda0 poll_oneoff test: don't try to poll same fd for read and write 2021-04-27 17:41:07 -07:00
Chris Fallin
b89c959e4a Merge pull request #2854 from uweigand/debug-endian
debug: Support big-endian architectures
2021-04-27 10:27:22 -07:00
Alex Crichton
8384f3a347 Bring back Module::deserialize (#2858)
* Bring back `Module::deserialize`

I thought I was being clever suggesting that `Module::deserialize` was
removed from #2791 by funneling all module constructors into
`Module::new`. As our studious fuzzers have found, though, this means
that `Module::new` is not safe currently to pass arbitrary user-defined
input into. Now one might pretty reasonable expect to be able to do
that, however, being a WebAssembly engine and all. This PR as a result
separates the `deserialize` part of `Module::new` back into
`Module::deserialize`.

This means that binary blobs created with `Module::serialize` and
`Engine::precompile_module` will need to be passed to
`Module::deserialize` to "rehydrate" them back into a `Module`. This
restores the property that it should be safe to pass arbitrary input to
`Module::new` since it's always expected to be a wasm module. This also
means that fuzzing will no longer attempt to fuzz `Module::deserialize`
which isn't something we want to do anyway.

* Fix an example

* Mark `Module::deserialize` as `unsafe`
2021-04-27 10:55:12 -05:00
Pat Hickey
a532d0f379 subscribe to mut fds 2021-04-26 16:42:02 -07:00
Pat Hickey
867d2c9a35 follow the types 2021-04-26 15:49:27 -07:00
Pat Hickey
b307dce2ab add readable and writable futures to WasiFile trait 2021-04-26 14:43:16 -07:00
Pat Hickey
fa44ec2da2 tokio sched: comment out just to make it compile 2021-04-26 14:42:22 -07:00
Ulrich Weigand
801358333d debug: Support big-endian architectures
This fixes some hard-coded assumptions in the debug crate that
the native ELF files being accessed are little-endian; specifically
in create_gdbjit_image as well as in emit_dwarf.

In addition, data in WebAssembly memory always uses little-endian
byte order.  Therefore, if the native architecture is big-endian,
all references to base types need to be marked as little-endian
using the DW_AT_endianity attribute, so that the debugger will
be able to correctly access them.
2021-04-21 14:14:59 +02:00
Alex Crichton
196bcec6cf Process declared element segments for "possibly exported funcs" (#2851)
Now that we're using "possibly exported" as an impactful decision for
codegen (which trampolines to generate and which ABI a function has)
it's important that we calculate this property of a wasm function
correctly! Previously Wasmtime forgot to processed "declared" elements
in apart from active/passive element segments, but this updates Wasmtime
to ensure that these entries are processed and all the functions
contained within are flagged as "possibly exported".

Closes #2850
2021-04-20 16:52:51 -05:00
Alex Crichton
200d7f1df6 Delete signature for no-longer-present function (#2849)
Accidental omission from #2736
2021-04-19 20:49:33 -05:00
Alex Crichton
193551a8d6 Optimize table.init instruction and instantiation (#2847)
* Optimize `table.init` instruction and instantiation

This commit optimizes table initialization as part of instance
instantiation and also applies the same optimization to the `table.init`
instruction. One part of this commit is to remove some preexisting
duplication between instance instantiation and the `table.init`
instruction itself, after this the actual implementation of `table.init`
is optimized to effectively have fewer bounds checks in fewer places and
have a much tighter loop for instantiation.

A big fallout from this change is that memory/table initializer offsets
are now stored as `u32` instead of `usize` to remove a few casts in a
few places. This ended up requiring moving some overflow checks that
happened in parsing to later in code itself because otherwise the wrong
spec test errors are emitted during testing. I've tried to trace where
these can possibly overflow but I think that I managed to get
everything.

In a local synthetic test where an empty module with a single 80,000
element initializer this improves total instantiation time by 4x (562us
=> 141us)

* Review comments
2021-04-19 18:44:48 -05:00
Pat Hickey
3d3a2acc1b wasi-tokio: WIP need to port the sync scheduler into a spawn_blocking 2021-04-19 16:00:38 -07:00
Pat Hickey
8667d8c244 test-programs: test wasi-tokio 2021-04-19 16:00:27 -07:00
Nick Fitzgerald
2864bb4a0f Merge pull request #2848 from fitzgen/map-or-in-table-element-into-raw
Use `map_or` instead of `map` and `unwrap_or` in `TableElement::into_raw`
2021-04-19 15:45:12 -07:00
Pat Hickey
675b579361 use AsyncSeek 2021-04-19 14:35:46 -07:00
Nick Fitzgerald
8507eb7708 Use map_or instead of map and unwrap_or in TableElement::into_raw 2021-04-19 14:18:55 -07:00
Peter Huene
f12b4c467c Add resource limiting to the Wasmtime API. (#2736)
* Add resource limiting to the Wasmtime API.

This commit adds a `ResourceLimiter` trait to the Wasmtime API.

When used in conjunction with `Store::new_with_limiter`, this can be used to
monitor and prevent WebAssembly code from growing linear memories and tables.

This is particularly useful when hosts need to take into account host resource
usage to determine if WebAssembly code can consume more resources.

A simple `StaticResourceLimiter` is also included with these changes that will
simply limit the size of linear memories or tables for all instances created in
the store based on static values.

* Code review feedback.

* Implemented `StoreLimits` and `StoreLimitsBuilder`.
* Moved `max_instances`, `max_memories`, `max_tables` out of `Config` and into
  `StoreLimits`.
* Moved storage of the limiter in the runtime into `Memory` and `Table`.
* Made `InstanceAllocationRequest` use a reference to the limiter.
* Updated docs.
* Made `ResourceLimiterProxy` generic to remove a level of indirection.
* Fixed the limiter not being used for `wasmtime::Memory` and
  `wasmtime::Table`.

* Code review feedback and bug fix.

* `Memory::new` now returns `Result<Self>` so that an error can be returned if
  the initial requested memory exceeds any limits placed on the store.

* Changed an `Arc` to `Rc` as the `Arc` wasn't necessary.

* Removed `Store` from the `ResourceLimiter` callbacks. Custom resource limiter
  implementations are free to capture any context they want, so no need to
  unnecessarily store a weak reference to `Store` from the proxy type.

* Fixed a bug in the pooling instance allocator where an instance would be
  leaked from the pool. Previously, this would only have happened if the OS was
  unable to make the necessary linear memory available for the instance. With
  these changes, however, the instance might not be created due to limits
  placed on the store. We now properly deallocate the instance on error.

* Added more tests, including one that covers the fix mentioned above.

* Code review feedback.

* Add another memory to `test_pooling_allocator_initial_limits_exceeded` to
  ensure a partially created instance is successfully deallocated.
* Update some doc comments for better documentation of `Store` and
  `ResourceLimiter`.
2021-04-19 09:19:20 -05:00
Taiki Endo
52b1166918 Update iter-enum to 1 (#2846) 2021-04-19 09:08:15 -05:00
Peter Huene
ef2ad6375d Consolidate module construction.
This commit adds `Module::from_parts` as an internal constructor that shared
the implementation between `Module::from_binary` and module deserialization.
2021-04-16 12:34:38 -07:00
Peter Huene
dfab471ce5 Remove unused file.
This file hasn't been used for a while and was mistakenly not deleted.
2021-04-16 12:30:14 -07:00
Peter Huene
b775b68cfb Make module information lookup from runtime safe.
This commit uses a two-phase lookup of stack map information from modules
rather than giving back raw pointers to stack maps.

First the runtime looks up information about a module from a pc value, which
returns an `Arc` it keeps a reference on while completing the stack map lookup.

Second it then queries the module information for the stack map from a pc
value, getting a reference to the stack map (which is now safe because of the
`Arc` held by the runtime).
2021-04-16 12:30:10 -07:00
Peter Huene
6ac1321162 Minor corrections with latest changes. 2021-04-16 11:08:22 -07:00
Peter Huene
726a936474 Remove ArcModuleCode as it is no longer used. 2021-04-16 11:08:22 -07:00
Peter Huene
510fc71728 Code review feedback.
* Make `FunctionInfo` public and `CompiledModule::func_info` return it.
* Make the `StackMapLookup` trait unsafe.
* Add comments for the purpose of `EngineHostFuncs`.
* Rework ownership model of shared signatures: `SignatureCollection` in
  conjunction with `SignatureRegistry` is now used so that the `Engine`,
  `Store`, and `Module` don't need to worry about unregistering shared
  signatures.
* Implement `Func::param_arity` and `Func::result_arity` in terms of
  `Func::ty`.
* Make looking up a trampoline with the module registry more efficient by doing
  a binary search on the function's starting PC value for the owning module and
  then looking up the trampoline with only that module.
* Remove reference to the shared signatures from `GlobalRegisteredModule`.
2021-04-16 11:08:21 -07:00
Peter Huene
ea72c621f0 Remove the stack map registry.
This commit removes the stack map registry and instead uses the existing
information from the store's module registry to lookup stack maps.

A trait is now used to pass the lookup context to the runtime, implemented by
`Store` to do the lookup.

With this change, module registration in `Store` is now entirely limited to
inserting the module into the module registry.
2021-04-16 11:08:21 -07:00
Peter Huene
a2466b3c23 Move the signature registry into Engine.
This commit moves the shared signature registry out of `Store` and into
`Engine`.

This helps eliminate work that was performed whenever a `Module` was
instantiated into a `Store`.

Now a `Module` is registered with the shared signature registry upon creation,
storing the mapping from the module's signature index space to the shared index
space.

This also refactors the "frame info" registry into a general purpose "module
registry" that is used to look up trap information, signature information, and
(soon) stack map information.
2021-04-16 11:06:44 -07:00
Benjamin Bouvier
ba73b458b8 Introduce a new API that allows notifying that a Store has moved to a new thread (#2822)
* Introduce a new API that allows notifying that a Store has moved to a new thread

* Add backlink to documentation, and mention the new API in the multithreading doc;
2021-04-16 11:15:35 -05:00
Pat Hickey
d2a98ced53 use some better traits 2021-04-15 16:00:11 -07:00
Pat Hickey
9880d09f1f do some programming 2021-04-15 14:50:17 -07:00
Pat Hickey
33dbd4388c use tokio's File with a cap-std Dir 2021-04-15 11:39:11 -07:00