|
|
|
|
[package]
|
|
|
|
|
name = "wasmtime-cli"
|
|
|
|
|
version = "0.25.0"
|
|
|
|
|
authors = ["The Wasmtime Project Developers"]
|
|
|
|
|
description = "Command-line interface for Wasmtime"
|
|
|
|
|
license = "Apache-2.0 WITH LLVM-exception"
|
|
|
|
|
documentation = "https://bytecodealliance.github.io/wasmtime/cli.html"
|
|
|
|
|
categories = ["wasm"]
|
|
|
|
|
keywords = ["webassembly", "wasm"]
|
|
|
|
|
repository = "https://github.com/bytecodealliance/wasmtime"
|
|
|
|
|
readme = "README.md"
|
|
|
|
|
edition = "2018"
|
|
|
|
|
default-run = "wasmtime"
|
|
|
|
|
|
|
|
|
|
[lib]
|
|
|
|
|
doctest = false
|
|
|
|
|
|
|
|
|
|
[[bin]]
|
|
|
|
|
name = "wasmtime"
|
|
|
|
|
path = "src/bin/wasmtime.rs"
|
|
|
|
|
doc = false
|
|
|
|
|
|
|
|
|
|
[dependencies]
|
|
|
|
|
# Enable all supported architectures by default.
|
|
|
|
|
wasmtime = { path = "crates/wasmtime", version = "0.25.0", default-features = false, features = ['cache'] }
|
|
|
|
|
wasmtime-cache = { path = "crates/cache", version = "0.25.0" }
|
|
|
|
|
wasmtime-debug = { path = "crates/debug", version = "0.25.0" }
|
|
|
|
|
wasmtime-environ = { path = "crates/environ", version = "0.25.0" }
|
|
|
|
|
wasmtime-jit = { path = "crates/jit", version = "0.25.0" }
|
|
|
|
|
wasmtime-obj = { path = "crates/obj", version = "0.25.0" }
|
|
|
|
|
wasmtime-wast = { path = "crates/wast", version = "0.25.0" }
|
|
|
|
|
wasmtime-wasi = { path = "crates/wasi", version = "0.25.0" }
|
|
|
|
|
wasmtime-wasi-crypto = { path = "crates/wasi-crypto", version = "0.25.0", optional = true }
|
|
|
|
|
wasmtime-wasi-nn = { path = "crates/wasi-nn", version = "0.25.0", optional = true }
|
|
|
|
|
structopt = { version = "0.3.5", features = ["color", "suggestions"] }
|
|
|
|
|
object = { version = "0.23.0", default-features = false, features = ["write"] }
|
|
|
|
|
anyhow = "1.0.19"
|
cranelift: add support for the Mac aarch64 calling convention
This bumps target-lexicon and adds support for the AppleAarch64 calling
convention. Specifically for WebAssembly support, we only have to worry
about the new stack slots convention. Stack slots don't need to be at
least 8-bytes, they can be as small as the data type's size. For
instance, if we need stack slots for (i32, i32), they can be located at
offsets (+0, +4). Note that they still need to be properly aligned on
the data type they're containing, though, so if we need stack slots for
(i32, i64), we can't start the i64 slot at the +4 offset (it must start
at the +8 offset).
Added one test that was failing on the Mac M1, as well as other tests
stressing different yet similar situations.
4 years ago
|
|
|
target-lexicon = { version = "0.12.0", default-features = false }
|
|
|
|
|
pretty_env_logger = "0.4.0"
|
|
|
|
|
file-per-thread-logger = "0.1.1"
|
|
|
|
|
wat = "1.0.36"
|
|
|
|
|
libc = "0.2.60"
|
externref: implement stack map-based garbage collection
For host VM code, we use plain reference counting, where cloning increments
the reference count, and dropping decrements it. We can avoid many of the
on-stack increment/decrement operations that typically plague the
performance of reference counting via Rust's ownership and borrowing system.
Moving a `VMExternRef` avoids mutating its reference count, and borrowing it
either avoids the reference count increment or delays it until if/when the
`VMExternRef` is cloned.
When passing a `VMExternRef` into compiled Wasm code, we don't want to do
reference count mutations for every compiled `local.{get,set}`, nor for
every function call. Therefore, we use a variation of **deferred reference
counting**, where we only mutate reference counts when storing
`VMExternRef`s somewhere that outlives the activation: into a global or
table. Simultaneously, we over-approximate the set of `VMExternRef`s that
are inside Wasm function activations. Periodically, we walk the stack at GC
safe points, and use stack map information to precisely identify the set of
`VMExternRef`s inside Wasm activations. Then we take the difference between
this precise set and our over-approximation, and decrement the reference
count for each of the `VMExternRef`s that are in our over-approximation but
not in the precise set. Finally, the over-approximation is replaced with the
precise set.
The `VMExternRefActivationsTable` implements the over-approximized set of
`VMExternRef`s referenced by Wasm activations. Calling a Wasm function and
passing it a `VMExternRef` moves the `VMExternRef` into the table, and the
compiled Wasm function logically "borrows" the `VMExternRef` from the
table. Similarly, `global.get` and `table.get` operations clone the gotten
`VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the
reference out of the table.
When a `VMExternRef` is returned to host code from a Wasm function, the host
increments the reference count (because the reference is logically
"borrowed" from the `VMExternRefActivationsTable` and the reference count
from the table will be dropped at the next GC).
For more general information on deferred reference counting, see *An
Examination of Deferred Reference Counting and Cycle Detection* by Quinane:
https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf
cc #929
Fixes #1804
4 years ago
|
|
|
log = "0.4.8"
|
|
|
|
|
rayon = "1.2.1"
|
|
|
|
|
humantime = "2.0.0"
|
|
|
|
|
wasmparser = "0.77.0"
|
|
|
|
|
|
|
|
|
|
[dev-dependencies]
|
|
|
|
|
env_logger = "0.8.1"
|
|
|
|
|
filecheck = "0.5.0"
|
|
|
|
|
more-asserts = "0.2.1"
|
|
|
|
|
tempfile = "3.1.0"
|
|
|
|
|
test-programs = { path = "crates/test-programs" }
|
|
|
|
|
wasmtime-fuzzing = { path = "crates/fuzzing" }
|
|
|
|
|
wasmtime-runtime = { path = "crates/runtime" }
|
|
|
|
|
tracing-subscriber = "0.2.16"
|
|
|
|
|
wast = "35.0.0"
|
|
|
|
|
|
|
|
|
|
[build-dependencies]
|
|
|
|
|
anyhow = "1.0.19"
|
|
|
|
|
|
|
|
|
|
[profile.release.build-override]
|
|
|
|
|
opt-level = 0
|
|
|
|
|
|
|
|
|
|
[workspace]
|
|
|
|
|
resolver = '2'
|
|
|
|
|
members = [
|
|
|
|
|
"cranelift",
|
|
|
|
|
"crates/bench-api",
|
|
|
|
|
"crates/c-api",
|
|
|
|
|
"crates/fuzzing",
|
|
|
|
|
"crates/misc/run-examples",
|
|
|
|
|
"crates/misc/rust",
|
|
|
|
|
"crates/wiggle",
|
|
|
|
|
"crates/wiggle/generate",
|
|
|
|
|
"crates/wiggle/macro",
|
|
|
|
|
"crates/wiggle/wasmtime",
|
|
|
|
|
"crates/wasi-common",
|
|
|
|
|
"crates/wasi-common/cap-std-sync",
|
|
|
|
|
"examples/fib-debug/wasm",
|
|
|
|
|
"examples/wasi/wasm",
|
|
|
|
|
"fuzz",
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
[features]
|
|
|
|
|
default = ["jitdump", "wasmtime/wat", "wasmtime/parallel-compilation"]
|
|
|
|
|
lightbeam = ["wasmtime/lightbeam"]
|
|
|
|
|
jitdump = ["wasmtime/jitdump"]
|
|
|
|
|
vtune = ["wasmtime/vtune"]
|
|
|
|
|
wasi-crypto = ["wasmtime-wasi-crypto"]
|
|
|
|
|
wasi-nn = ["wasmtime-wasi-nn"]
|
|
|
|
|
uffd = ["wasmtime/uffd"]
|
|
|
|
|
|
|
|
|
|
# Try the experimental, work-in-progress new x86_64 backend. This is not stable
|
|
|
|
|
# as of June 2020.
|
|
|
|
|
experimental_x64 = ["wasmtime-jit/experimental_x64"]
|
|
|
|
|
|
|
|
|
|
[badges]
|
|
|
|
|
maintenance = { status = "actively-developed" }
|
|
|
|
|
|
|
|
|
|
[[test]]
|
|
|
|
|
name = "host_segfault"
|
|
|
|
|
harness = false
|
externref: implement stack map-based garbage collection
For host VM code, we use plain reference counting, where cloning increments
the reference count, and dropping decrements it. We can avoid many of the
on-stack increment/decrement operations that typically plague the
performance of reference counting via Rust's ownership and borrowing system.
Moving a `VMExternRef` avoids mutating its reference count, and borrowing it
either avoids the reference count increment or delays it until if/when the
`VMExternRef` is cloned.
When passing a `VMExternRef` into compiled Wasm code, we don't want to do
reference count mutations for every compiled `local.{get,set}`, nor for
every function call. Therefore, we use a variation of **deferred reference
counting**, where we only mutate reference counts when storing
`VMExternRef`s somewhere that outlives the activation: into a global or
table. Simultaneously, we over-approximate the set of `VMExternRef`s that
are inside Wasm function activations. Periodically, we walk the stack at GC
safe points, and use stack map information to precisely identify the set of
`VMExternRef`s inside Wasm activations. Then we take the difference between
this precise set and our over-approximation, and decrement the reference
count for each of the `VMExternRef`s that are in our over-approximation but
not in the precise set. Finally, the over-approximation is replaced with the
precise set.
The `VMExternRefActivationsTable` implements the over-approximized set of
`VMExternRef`s referenced by Wasm activations. Calling a Wasm function and
passing it a `VMExternRef` moves the `VMExternRef` into the table, and the
compiled Wasm function logically "borrows" the `VMExternRef` from the
table. Similarly, `global.get` and `table.get` operations clone the gotten
`VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the
reference out of the table.
When a `VMExternRef` is returned to host code from a Wasm function, the host
increments the reference count (because the reference is logically
"borrowed" from the `VMExternRefActivationsTable` and the reference count
from the table will be dropped at the next GC).
For more general information on deferred reference counting, see *An
Examination of Deferred Reference Counting and Cycle Detection* by Quinane:
https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf
cc #929
Fixes #1804
4 years ago
|
|
|
|
|
|
|
|
[profile.dev.package.backtrace]
|
|
|
|
|
debug = false # FIXME(#1813)
|
