* Fix preservation of the sigaltstack on macOS
This commit fixes an issue discovered in the wasmtime-go bindings when
the Go runtime was crashing on macOS only when running wasm code that
trapped. It turns out that our switch to `siglongjmp` from `longjmp`
actually broke macOS! This breakage happens because all subsequent
signals after the first signal are all delivered on the main stack, not
the sigaltstack, even if the sigaltstack is configured. This causes the
Go runtime to crash since it expects to run on the sigaltstack.
The fix in this commit is to actually return from the signal handler to
trigger the kernel's updating of the sigaltstack no longer being in use.
Before we return, however, we configure the register context to return
to to call some custom code which immediately does the unwind we would
otherwise have done. This works around the issue on macOS hopefully
without adding too many portability problems. Ideally this will all go
away as well with #2632 as well.
* Fix compile warning
This adds the ability to add feature flags (e.g. `--features wasi-nn`) when compiling `wasmtime-bench-api` to allow benchmarking Wasmtime with WASI proposals included. Note that due to https://github.com/rust-lang/cargo/issues/5364, these features are only available:
- in the `crates/bench-api` directory, e.g. `pushd crates/bench-api; cargo build --features wasi-crypto`
- or from the top-level project directory using `-Zpackage-features`, e.g. `OPENVINO_INSTALL_DIR=/opt/intel/openvino cargo +nightly build -p wasmtime-bench-api -Zpackage-features --features wasi-nn`
* Don't use HTML comments, as they are noisy, which makes the templates more
intimidating.
* Use "TODO" to clearly demarcate everywhere the issue reporter should fill in
some information.
* Use headers and white space abundantly, which makes it easier to visually
process the template and its sections at a glance, and less of an intimidating
wall of text.
Fixes#2661
This commit updates to the 0.9 version of the witx crate implemented in
WebAssembly/wasi#395. This new version drastically changes code
generation and how we interface with the crate. The intention is to
abstract the code generation aspects and allow code generators to
implement much more low-level instructions to enable more flexible APIs
in the future. Additionally a bunch of `*.witx` files were updated in
the WASI repository.
It's worth pointing out, however, that `wasi-common` does not change as
a result of this change. The shape of the APIs that we need to implement
are effectively the same and the only difference is that the shim
functions generated by wiggle are a bit different.
This updates the publication script we have for crates to ensure that
the `wasmtime-publish` GitHub team is added to all crates published.
This will fail for most publications because the team is already listed,
but the hope is that whomever is publishing can see the logs and catch
anything that looks awry.
This unifies the logic around Rex prefix emission and hopefully makes REX prefix errors less likely.
There are still several instructions that use other sources to determine the flags, so set_w and clear_w are left as is.
Additional cleanups:
* Change always_emit_if_8bit_needed to take a Reg instead of a u8 for type safety.
* Deduplicated emission code in MovRM.
- Panic messages must now be string literals (we used `format!()` in
many places; `panic!()` can take format strings directly).
- Some dead enum options with EVEX encoding stuff in old x86 backend.
This will go away soon and/or be moved to the new backend anyway, so
let's silence the warning for now.
- A few other misc warnings.
the fdstat of a dirfd needs to include both the file and dir rights in
the inheriting field.
The wasi-libc path_open bases the base rights of child directories off
the inheriting rights of the parent, so if we only put file rights in
there, opening a child directory will not have any directory operations
permitted.
Fixes https://github.com/bytecodealliance/wasmtime/issues/2638
* Ensure `store` is in the function names
* Don't abort the process on `add_fuel` when fuel isn't configured
* Allow learning about failure in both `add_fuel` and `fuel_consumed`
Apparently on macOS `setjmp` manipulates the process-wide signal mask
which adds a good deal of overhead. We don't actually need this
functionality so this commit switches to using the `sig` version of
setjmp/longjmp where we can explicitly ask the signal mask to not get
preserved. This came out of poking around on #2644 and on macOS locally
thi sdropped the overhead from 721ns to 55ns.
