Refactor `sync_nostd.rs` silghtly (#11875)

* Refactor `sync_nostd.rs` silghtly

Model the `#[cfg(has_custom_sync)]` distinction with modules rather than
`#[cfg]` throughout the code. No fundamental

Refactor `sync_nostd.rs` silghtly (#11875)

* Refactor `sync_nostd.rs` silghtly

Model the `#[cfg(has_custom_sync)]` distinction with modules rather than
`#[cfg]` throughout the code. No fundamental change to the
implementations here, just shuffling things around.

Also refactor the `wasmtime-platform.c` file to deduplicate the lazy
init of pthread primitives notably for the rwlock implementation.

* Fix unused import

show more ...

feat(no_std): Add custom sync primitives support via C API (#11836)

* Add custom-sync-primitives feature for no_std environments

This adds a new `custom-sync-primitives` feature that allows embedde

feat(no_std): Add custom sync primitives support via C API (#11836)

* Add custom-sync-primitives feature for no_std environments

This adds a new `custom-sync-primitives` feature that allows embedders
to provide their own synchronization primitives through a C API. This
is particularly useful for kernel and embedded environments that need
custom lock implementations.

The implementation follows the existing pattern of `custom-virtual-memory`
and `custom-native-signals`, providing host-provided implementations of
OnceLock and RwLock through callback functions defined in the C API.

* assume no_std in has_custom_sync flag

* updating panic on contention error messages in sync_nostd.rs

* inlining free in drop in custom/sync.rs

* simplifying custom/sync.rs to delegate lazy initialization to the embedder

* Consolidate no_std sync implementations and add RwLock-specific C API

* Minor cleanup

* adding custom_sync support to min-platform example

* adding multithreaded TLS using pthread to min-platform example

* addressing PR comments:
Remove *_new files from capi sync api.
Implement Drop-based lock releasing
Update documentation + minor changes

* fixes min-platform example for sync primitives
Use heap allocation to avoid deadlock in the implementation with no heap allocation.
Use compare-and-swap for lazy initialization of rw lock for thread safety.

* upgrade cbindgen in CI to 0.29

* undo accidental edits to cbindgen generated header file

show more ...

Replace setjmp/longjmp usage in Wasmtime (#11592)

Since Wasmtime's inception it's used the `setjmp` and `longjmp`
functions in C to implement handling of traps. While this solution was
easy to imple

Replace setjmp/longjmp usage in Wasmtime (#11592)

Since Wasmtime's inception it's used the `setjmp` and `longjmp`
functions in C to implement handling of traps. While this solution was
easy to implement, relatively portable, and performant enough, there are
a number of downsides that have evolved over time to make this an
unattractive approach in the long run:

* Using `setjmp` fundamentally requires using C because Rust does not
understand a function that returns twice. It's fundamentally unsound
to invoke `setjmp` in Rust meaning that Wasmtime has forever needed a
C compiler configured and set up to build. This notably means that
`cargo check` cannot check other targets easily.

* Using `longjmp` means that Rust function frames are unwound on the
stack without running destructors. This is a dangerous operation of
which we get no protection from the compiler about. Both frames
entering wasm and frames exiting wasm are all skipped. Absolutely
minimizing this has been beneficial for portability to platforms such
as Pulley.

* Currently the no_std implementation of Wasmtime requires embedders to
provide `wasmtime_{setjmp,longjmp}` which is a thorn in the side of
what is otherwise a mostly entirely independent implementation of
Wasmtime.

* There is a performance floor to using `setjmp` and `longjmp`. Calling
`setjmp` requires using C but Wasmtime is otherwise written in Rust
meaning that there's a Rust->C->Rust->Wasm boundary which
fundamentally can't be inlined without cross-language LTO which is
difficult to configure.

* With the implementation of the WebAssembly exceptions proposal
Wasmtime now has two means of unwinding the stack. Ideally Wasmtime
would only have one, and the more general one is the method of
exceptions.

* Jumping out of a signal handler on Unix is tricky business. While
we've made it work it's generally most robust of the signal handler
simply returns which it now does.

With all of that in mind the purpose of this commit is to replace the
setjmp/longjmp mechanism of handling traps with the recently implemented
support for exceptions in Cranelift. That is intended to resolve all of
the above points in one swoop.

One point in particular though that's nice about setjmp/longjmp is that
unwinding the stack on a trap is an O(1) operation. For situations such
as stack overflow that's a particularly nice property to have as we can
guarantee embedders that traps are a constant time (albeit somewhat
expensive with signals) operation. Exceptions naively require unwinding
the entire stack, and although frame pointers mean we're just traversing
a linked list I wanted to preserve the O(1) property here nonetheless.
To achieve this a solution is implemented where the array-to-wasm
(host-to-wasm) trampolines setup state in `VMStoreContext` so looking up
the current trap handler frame is an O(1) operation. Namely the sp/fp/pc
values for a `Handler` are stored inline.

Implementing this feature required supporting
relocations-to-offsets-in-functions which was not previously supported
by Wasmtime. This required Cranelift refactorings such as #11570, #11585,
and #11576. This then additionally required some more refactoring in
this commit which was difficult to split out as it otherwise wouldn't be
tested.

Apart from the relocation-related business much of this change is about
updating the platform signal handlers to use exceptions instead of
longjmp to return. For example on Unix this means updating the
`ucontext_t` with register values that the handler specifies. Windows
involves updating similar contexts, and macOS mach ports ended up not
needing too many changes.

In terms of overall performance the relevant benchmark from this
repository, compared to before this commit, is:

sync/no-hook/core - host-to-wasm - typed - nop
time: [10.552 ns 10.561 ns 10.571 ns]
change: [−7.5238% −7.4011% −7.2786%] (p = 0.00 < 0.05)
Performance has improved.

Closes #3927
cc #10923

prtest:full

show more ...

Replace `signals-based-traps` with auto-detection (#9941)

* Replace `signals-based-traps` with auto-detection

This commit refactors the platform support of the `wasmtime` crate
itself to remove the

Replace `signals-based-traps` with auto-detection (#9941)

* Replace `signals-based-traps` with auto-detection

This commit refactors the platform support of the `wasmtime` crate
itself to remove the previously added `signals-based-traps` feature in
favor of auto-detecting whether it's there or not. The `build.rs`
script for the `wasmtime` crate will now detect the target platform and
auto-enable this feature as necessary.

The `signals-based-traps` cargo feature is removed and split into two
custom `#[cfg]` directives that the build script sets:

* `has_virtual_memory` - this is used to gate mmap implementations for
example. This is enabled on `unix || windows` and will be off for
`no_std` targets for example. This is split out of
"signals-based-traps" to better handle platforms like iOS which have
virtual memory but don't execute native code (removing the need for
native signals).

* `has_native_signals` - gates signal handlers on Unix for example. This
is disabled on MIRI but otherwise enabled for `unix || windows`. This
is intended to in the future get disabled for iOS by default for
example since it's not necessary when using Pulley. This is
additionally off-by-default for `no_std` platforms.

Two new crate features were added for `no_std` or "custom" platforms to
opt-in to the `wasmtime-platform.h` C APIs for implementing virtual
memory and signals. These are used in the `min-platform` embedding example.

This commit additionally updates some various documentation here and
there to be more up-to-date.

* Update CI configuration

* Fix compile warnings

* Fix test on miri

* Fix more tests on miri

* Fix some warnings

* Another round of miri/CI attempts/fixes

prtest:full

show more ...

Update the host ABI of Wasmtime to return failure (#9675)

* Update the host ABI of Wasmtime to return failure

This commit updates the "array call" ABI of Wasmtime used to transition
from wasm to th

Update the host ABI of Wasmtime to return failure (#9675)

* Update the host ABI of Wasmtime to return failure

This commit updates the "array call" ABI of Wasmtime used to transition
from wasm to the host to explicitly return a `bool` indicating whether
the call succeeded or not. Previously functions would implicitly unwind
via `longjmp` and thus no explicit checks were necessary. The burden of
unwinding is now placed on Cranelift-compiled code itself instead of the
caller.

There are a few pieces of rationale for this change:

* Primarily I was implementing initial integration of Pulley where the
host `setjmp` and `longjmp` cannot be used to maintain the Pulley
interpreter state. My initial plan for handling this was to handle
traps a bit differently in Pulley where having direct access to
whether a function trapped or not in the interpreter bytecode is
easier to deal with.

* Additionally it's generally not safe to call `longjmp` from Rust as it
will not run on-stack destructors. This is ok today in the sense that
we shouldn't have these in Wasmtime, but directly returning to
compiled code improves our safety story here a bit where we just won't
have to deal with the problem of skipping destructors.

* In the future I'd like to move away from `setjmp` and `longjmp`
entirely in the host to a Cranelift-native solution. This change would
be required for such a migration anyway so it's my hope to make such a
Cranelift-based implementation easier in the future. This might be
necessary, for example, when implementing the `exception-handling`
proposal for Wasmtime.

Functionally this commit does not remove all usages of
call-`longjmp`-from-Rust. Notably all libcalls and builtins still use
this helper in the trampolines generated in Rust. I plan on going
through the libcalls and updating their ABIs and signatures to reflect
this in follow-up commits. As a result a few preexisting functions that
should go away are marked `#[deprecated]` for internal use in this
commit. I'll be cleaning that up as follow-ups. For now this commit
handles the "hard part" of host functions by ensuring that the new
`bool` return value is plumbed in all the locations correctly.

prtest:full

* Hack around Windows MinGW miscompile (?)

* Run clang-format

show more ...

Add a `signals-based-traps` Cargo compile-time feature (#9614)

* Gate signal handlers behind a new Cargo feature

This commit adds a new on-by-default Cargo feature to the `wasmtime`
crate named `si

Add a `signals-based-traps` Cargo compile-time feature (#9614)

* Gate signal handlers behind a new Cargo feature

This commit adds a new on-by-default Cargo feature to the `wasmtime`
crate named `signals-based-traps`. This is modeled after the
`Config::signals_based_traps` configuration at runtime and can be used
to statically disable the use of signal handlers in Wasmtime. This
notably reduces the number of platform dependencies that Wasmtime has
and provides a mode of avoiding relying on signals altogether.

This introduces a new `MallocMemory` which is a linear memory backed by
the system allocator. This new type of memory is enabled when virtual
memory guards are disabled and signals-based-traps are disabled. This
means that this new type of memory will be candidate for fuzzing for
example.

prtest:full

* Fix rebase conflict

* Refactor `MmapVec` documentation and representation

* Remove no-longer-needed `Arc`
* Document it may be backed by `Vec<u8>`

show more ...

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 ...

Add a "custom" platform configuration for Wasmtime (#7995)

* Add a "custom" platform configuration for Wasmtime

This commit leverages adds a new "platform" to Wasmtime to be supported
in the `crate

Add a "custom" platform configuration for Wasmtime (#7995)

* Add a "custom" platform configuration for Wasmtime

This commit leverages adds a new "platform" to Wasmtime to be supported
in the `crates/runtime/src/sys` folder. This joins preexisting platforms
such as Unix and Windows. The goal of this platform is to be an opt-in
way to build Wasmtime for targets that don't have a predefined way to
run.

The new "custom" platform requires `--cfg wasmtime_custom_platform` to
be passed to the Rust compiler, for example by using `RUSTFLAGS`. This
new platform bottoms out in a C API that is intended to be small and
Linux-like. The C API is effectively the interface to virtual memory
that Wasmtime requires. This C API is also available as a header file at
`examples/min-platform/embedding/wasmtime-platform.h` (generated by
`cbindgen`).

The main purpose of this is to make it easier to experiment with porting
Wasmtime to new platforms. By decoupling a platform implementation from
Wasmtime itself it should be possible to run these experiments
out-of-tree. An example of this I've been working on is getting
Wasmtime running on bare-metal with a custom kernel. This support
enables defining the platform interface of the custom kernel's syscalls
outside of Wasmtime.

* Exclude wasmtime-platform.h from formatting

* Include build-wasmtime-target-wasm32 in final job

* Don't force any single toolchain

* Add notes to no_std docs

* Add rust-src to CI

* Review comments

* Change APIs to be fallible

* Only compile the min-platform example on Linux

* Fix compile of min-platform example

* Fix another compile error in the example

show more ...