Add basic support for profiling Pulley (#10034)

* Add basic support for profiling Pulley

This commit adds basic support for profiling the Pulley interpreter.
This is partially achievable previously

Add basic support for profiling Pulley (#10034)

* Add basic support for profiling Pulley

This commit adds basic support for profiling the Pulley interpreter.
This is partially achievable previously through the use of native
profilers, but the downside of that approach is that you can find hot
instructions but it's not clear in what context the hot instructions are
being executed nor what functions are hot. The goal of this profiler is
to show pulley bytecode and time spent in bytecode itself to better
understand the shape of code around a hot instruction to identify new
macro opcodes for example.

The general structure of this new profiler is:

* There is a compile-time feature for Pulley which is off-by-default
where, when enabled, Pulley will record its current program counter
into an `AtomicUsize` before each instruction.

* When the CLI has `--profile pulley` Wasmtime will spawn a sampling
thread in the same process which will periodically read from this
`AtomicUsize` to record where the program is currently executing.

* The Pulley profiler additionally records all bytecode through the use
of the `ProfilingAgent` trait to ensure that the recording has access
to all bytecode as well.

* Samples are taken throughout the process and emitted to a
`pulley-$pid.data` file. This file is then interpreted and printed by
an "example" program `profiler-html.rs` in the `pulley/examples`
directory.

The end result is that hot functions of Pulley bytecode can be seen and
instructions are annotated with how frequently they were executed. This
enables finding hot loops and understanding more about the whole loop,
bytecodes that were selected, and such.

* Add missing source file

* Check the profile-pulley feature in CI

* Miscellaneous fixes for CI

* Fix type-checking of `become` on nightly Rust

* Fix more misc CI issues

* Fix dispatch in tail loop

* Update test expectations

* Review comments

* Fix a feature combo

show more ...

Some minor portability tweaks (#9538)

* Change vtune platforms to be opt-in

Previously integration with the `ittapi` crate and vtune profiling was
statically enabled for all platforms with an expli

Some minor portability tweaks (#9538)

* Change vtune platforms to be opt-in

Previously integration with the `ittapi` crate and vtune profiling was
statically enabled for all platforms with an explicit list of platforms
that did not support it. Instead of requiring platforms to indicate they
don't support it (as it's an optional feature) this instead inverts
things to instead explicitly list platforms that do support it. The hope
is that this helps to make porting a bit easier where manual work is
only needed to get vtune running on a new platform.

* Add illumos to tier listings

* Improve check we compile on FreeBSD

The crate should compile by default (ideally) and it does now so assert
this in CI.

* Clarify x86_64 freebsd is a tier 3 target

show more ...

add experimental support for illumos (#9535)

With this change, the basic wasm tests all pass on illumos. Note the addition
of NORESERVE to mmap calls.

However:

While wasmtime appears to be functio

add experimental support for illumos (#9535)

With this change, the basic wasm tests all pass on illumos. Note the addition
of NORESERVE to mmap calls.

However:

While wasmtime appears to be functional on illumos, it is still quite slow,
particularly in the wast tests. For example, the following test:

```
cargo +beta test --test wast -- Cranelift/pooling/tests/spec_testsuite/load.wast
```

takes 0.07 seconds on Linux, but over 5 seconds on illumos. Some profiling
suggests that this is due to lock contention inside the kernel while freeing
memory, so I don't think this is a wasmtime issue. I'd like to pull some
illumos experts in to do some debugging here as time permits, but I don't think
this PR should necessarily be held up on that.

Thanks to iximeow for all the help with this!

(One note is that due to a [rustc segfault on
illumos](https://sunshowers.io/posts/rustc-segfault-illumos/), building
wasmtime requires Rust 1.83 or higher. I did my building and testing with
`+beta`.)

show more ...

Refactor internal profiling APIs to be safer (#8914)

Pass around `&[u8]` instead of `*const u8` and `usize` to avoid the need
for raw unsafe abstractions.

Closes #8905

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

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

Fix more nightly warnings (#7907)

Additionally give `-Zcheck-cfg` a spin with Cargo and fix some mistakes
with our `--cfg` and `#[cfg]` directives.

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

Remove `wasmtime-jit` (#7769)

* Move `jit` crate to `environ`

Move the platform agnostic parts of the crate `wasmtime-jit` to
`wasmtime-environ`. This is the first part of the refactoring discussed

Remove `wasmtime-jit` (#7769)

* Move `jit` crate to `environ`

Move the platform agnostic parts of the crate `wasmtime-jit` to
`wasmtime-environ`. This is the first part of the refactoring discussed
here: https://github.com/bytecodealliance/wasmtime/issues/7652 and a
follow up will move the remaining parts of `wasmtime-jit` so that the
crate can be deleted.

* Move `jit` crate to `wasmtime`

Move the remaining parts of `wasmtime-jit` to the `wasmtime` crate and
remove `wasmtime-jit`. This is part of the refactoring discussed in
https://github.com/bytecodealliance/wasmtime/issues/7652.

* undo toml formatting

* Trigger pipeline: prtest:full

* Remove `jit` directory

* move `ProfilingAgent` out of `profiling` feature

* add links to ELF_NAME_DATA

show more ...