History log of /wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs (Results 1 – 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0, v32.0.0, v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0
# 980a136e 16-Jan-2025 Nick Fitzgerald <[email protected]>

Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)

* Wasmtime: generalize `async_stack_zeroing` knob to cover initialization

This commit moves the knob from the `Pooli

Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)

* Wasmtime: generalize `async_stack_zeroing` knob to cover initialization

This commit moves the knob from the `PoolingInstanceAllocatorConfig` to the
regular `Config` and now controls both whether stacks are zeroed before reuse
and whether they are zeroed before the initial use. The latter doesn't matter
usually, since anonymous mmaps are already zeroed so we don't have to do
anything there, but for no-std environments it is the difference between
manually zeroing the stack or simply using unininitialized memory.

* Fix CLI and test builds

* fix default config value

* fix some more tests

show more ...


Revision tags: v28.0.1, v28.0.0
# abcd6acc 04-Dec-2024 Chris Fallin <[email protected]>

Port wasmtime-fiber to `no_std` and allow `async` feature in `no_std` Wasmtime. (#9689)

This PR allows a `no_std` Wasmtime build to be configured with the
`async` feature. (Previously, a minimal `no

Port wasmtime-fiber to `no_std` and allow `async` feature in `no_std` Wasmtime. (#9689)

This PR allows a `no_std` Wasmtime build to be configured with the
`async` feature. (Previously, a minimal `no_std` configuration could
only run with sync entry points, without suspending of stacks.)

The main hurdle to this support was the `wasmtime-fiber` crate.
Fortunately, the "unix" variant of fibers was almost entirely portable
to a `no_std` environment, owing to the fact that it implements
stack-switching manually in assembly itself. I moved the per-ISA
implementations to a shared submodule and built the nostd platform
backend for `wasmtime-fiber` with a stripped-down version of the unix
backend.

The nostd backend does not support mmap'd stacks, does not support
custom stack allocators, and does not propagate panics.

prtest:full

show more ...


Revision tags: v27.0.0, v26.0.1, v25.0.3, v24.0.2, v26.0.0, v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1
# 110e70f3 26-Sep-2024 Alex Crichton <[email protected]>

Print an error on async stack overflow (#9304)

* Print an error on async stack overflow

This commit updates Wasmtime's handling of traps on Unix platforms to
print an error message on stack overflo

Print an error on async stack overflow (#9304)

* Print an error on async stack overflow

This commit updates Wasmtime's handling of traps on Unix platforms to
print an error message on stack overflow when the guard page is hit.
This is distinct from stack overflow in WebAssembly which raises a
normal trap and can be caught. This is instead to be used on
misconfigured hosts where the async stack is too small or wasm was
allowed to take up too much of the async stack. Currently no error
message is printed and the program simply aborts with a core dump which
can be difficult to debug.

This instead registers the range of the async guard page with the trap
handling infrastructure to test the faulting address and if it lies
within this range. If so then a small message is printed and then the
program is aborted with `libc::abort()`.

This does not impact the safety of any prior embedding or fix any
issues. It's instead intended purely as a diagnostic tool to help users
more quickly understand that stack size configuration settings are the
likely culprit.

* Fix build of c-api and tests

prtest:full

* Fix build on Windows

* Fix a warning on Windows

* Fix dead code on miri

show more ...


Revision tags: v25.0.1, v25.0.0, v24.0.0, v23.0.2, v23.0.1, v23.0.0, v22.0.0
# 1512a954 14-Jun-2024 Nick Fitzgerald <[email protected]>

Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)

* Add `anyhow` stuff to our internal `wasmtime` crate prelude

We use it basically everywhere and it is annoying to have to import

Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)

* Add `anyhow` stuff to our internal `wasmtime` crate prelude

We use it basically everywhere and it is annoying to have to import.

I also did an audit of existing `use` statements and removed the now-redundant
ones and replaced one-off imports with usage of the prelude, so that the prelude
is available by default in more places.

* Fix `cargo doc`

show more ...


Revision tags: v21.0.1, v21.0.0, v20.0.2
# 81a89169 04-May-2024 Alex Crichton <[email protected]>

Add support for `#![no_std]` to the `wasmtime` crate (#8533)

* Always fall back to custom platform for Wasmtime

This commit updates Wasmtime's platform support to no longer require an
opt-in `RUSTF

Add support for `#![no_std]` to the `wasmtime` crate (#8533)

* Always fall back to custom platform for Wasmtime

This commit updates Wasmtime's platform support to no longer require an
opt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becoming
officially supported this should provide a better onboarding experience
where the fallback custom platform is used. This will cause linker
errors if the symbols aren't implemented and searching/googling should
lead back to our docs/repo (eventually, hopefully).

* Change Wasmtime's TLS state to a single pointer

This commit updates the management of TLS to rely on just a single
pointer rather than a pair of a pointer and a `bool`. Additionally
management of the TLS state is pushed into platform-specific modules to
enable different means of managing it, namely the "custom" platform now
has a C function required to implement TLS state for Wasmtime.

* Delay conversion to `Instant` in atomic intrinsics

The `Duration` type is available in `no_std` but the `Instant` type is
not. The intention is to only support the `threads` proposal if `std` is
active but to assist with this split push the `Duration` further into
Wasmtime to avoid using a type that can't be mentioned in `no_std`.

* Gate more parts of Wasmtime on the `profiling` feature

Move `serde_json` to an optional dependency and gate the guest profiler
entirely on the `profiling` feature.

* Refactor conversion to `anyhow::Error` in `wasmtime-environ`

Have a dedicated trait for consuming `self` in addition to a
`Result`-friendly trait.

* Gate `gimli` in Wasmtime on `addr2line`

Cut down the dependency list if `addr2line` isn't enabled since then
the dependency is not used. While here additionally lift the version
requirement for `addr2line` up to the workspace level.

* Update `bindgen!` to have `no_std`-compatible output

Pull most types from Wasmtime's `__internal` module as the source of
truth.

* Use an `Option` for `gc_store` instead of `OnceCell`

No need for synchronization here when mutability is already available in
the necessary contexts.

* Enable embedder-defined host feature detection

* Add `#![no_std]` support to the `wasmtime` crate

This commit enables compiling the `runtime`, `gc`, and `component-model`
features of the `wasmtime` crate on targets that do not have `std`. This
tags the crate as `#![no_std]` and then updates everything internally to
import from `core` or `alloc` and adapt for the various idioms. This
ended up requiring some relatively extensive changes, but nothing too
too bad in the grand scheme of things.

* Require `std` for the perfmap profiling agent

prtest:full

* Fix build on wasm

* Fix windows build

* Remove unused import

* Fix Windows/Unix build without `std` feature

* Fix some doc links

* Remove unused import

* Fix build of wasi-common in isolation

* Fix no_std build on macos

* Re-fix build

* Fix standalone build of wasmtime-cli-flags

* Resolve a merge conflict

* Review comments

* Remove unused import

show more ...


Revision tags: v20.0.1, v20.0.0, v17.0.3, v19.0.2, v18.0.4, v19.0.1, v19.0.0, v18.0.3, v18.0.2, v17.0.2, v18.0.1, v18.0.0, v17.0.1
# d4242001 29-Jan-2024 Adam Bratschi-Kaye <[email protected]>

Support compilation-only build by adding a `runtime` feature (#7766)

* Add `runtime` feature to `wasmtime` crate

This feature can be disabled to build `wasmtime` only for compilation.
This can be u

Support compilation-only build by adding a `runtime` feature (#7766)

* Add `runtime` feature to `wasmtime` crate

This feature can be disabled to build `wasmtime` only for compilation.
This can be useful when cross-compiling, especially on a target that
can't run wasmtime itself (e.g. `wasm32`).

* prtest:full

* don't round pages without runtime feature

* fix async assertions

* move profiling into runtime

* enable runtime for wasmtime-wasi

* enable runtime for c-api

* fix build_artifacts in non-cache case

* fix miri extensions

* enable runtime for wast

* enable runtime for explorer

* support cranelift all-arch on wasm32

* add doc links for `WeakEngine`

* simplify lib runtime cfgs

* move limits and resources to runtime

* move stack to runtime

* move coredump and debug to runtime

* add runtime to coredump and async features

* add wasm32 build job

* combine engine modules

* single compile mod

* remove allow for macro paths

* add comments

show more ...