Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge with upstream #227

Merged
merged 41 commits into from
Sep 25, 2024
Merged

Merge with upstream #227

merged 41 commits into from
Sep 25, 2024

Conversation

dhil
Copy link
Member

@dhil dhil commented Sep 25, 2024

No description provided.

alexcrichton and others added 30 commits September 16, 2024 15:52
…9254)

This commit fixes a fuzz bug that cropped up over the weekend where a
config was being created with signals-based traps disabled and spectre
mitigations enabled which are incompatible configurations at this time.
The fix is to apply the "make this `Config` consistent" logic in another
location.
* Remove WasmtimeSystemV call conv

It is no longer used by Wasmtime

* Remove CallConv::extends_* methods

They all match only a single call conv anyway.

* Avoid isa:: prefix for referencing CallConv where possible

* Update callconv list in the clif ir reference

* Use push_non_formal where expected
…nds (bytecodealliance#9258)

Unlike x86_64 and some other architectures where large structs are
passed at fixed stack offsets, necessitating special Cranelift support,
arm64, riscv64 and s390x pass them using regular pointer arguments that
can trivially be implemented by frontends.

The current implementation of StructArgument on arm64 and riscv64 uses
fixed stack offsets just like on x86_64, which is incorrect as per the
ABI documentation. In other words any correct frontend already had
to avoid StructArgument on arm64 and riscv64 anyway. For s390x it is
correctly implemented but unnecessary and taints even non-s390x specific
code.
…e#9260)

Consolidate all `i31ref` special casing into the
`translate_{read,write}_gc_reference` methods, which already emit more or less
inline GC barriers depending on the reference's heap type, so it makes sense to
also handle `i31ref` there.

Co-authored-by: Trevor Elliott <[email protected]>
…ce#9257)

This commit updates the defaults of `PoolingAllocationConfig` to allow
unlimited core instances/memories/tables per component instead of the
previous default of 20. The limits here are somewhat restrictive and
more tailored for high-scale use cases which aren't always the best
defaults for a general purpose tool like the `wasmtime` CLI. The CLI for
example uses the pooling allocator by default with `serve` and this
helps accept a wider breadth of components by default instead of
artificially limiting the shape of input components.
…odule` (bytecodealliance#9261)

Because it returns the `wasmtime_environ::Module`.

This paves the way for a new method to get the `wasmtime::Module`.
* Add async tracing versions of the component-macro tests

* Use instrument when generating async call functions with tracing

* Update tests
…ealliance#9262)

* wit-bindgen: Don't trace values containing lists by default.

`list` values in Wit interfaces can represent things like HTTP bodies
which can be very large. To enable tracing without spamming logfiles
with all this data, put printing of values containing `list`s behind
a separate `verbose_tracing` option.

This is a coarse-grained approach; but it seems like a pretty good
default for tracing, and enabling full tracing when one needs it is
straightforward.

In the future, we may want to refine the option by implementing
the `Valuable` trait and using `tracing::field::valuable`, which
could allow us to do things like print non-`list` fields of records
that otherwise contain `list`s.

* Use `option_type_contains_lists` more.

* Hook up `verbose_tracing` to the macro.

* Update expected outputs for tests.
…9269)

With table64 support it's now possible that the number of desired table
elements can overflow the address space when multiplied by the size of
a pointer, so account for this when handling resource limits while fuzzing.
And do some minor refactors to the DRC collector to build other allocation
methods on top of that one internally.

This method will be used in forthcoming PRs implementing the
`struct.new[_default]` instructions, where a libcall does the actual allocation,
but Wasm code performs field initialization inline.
…ce#9273)

Copyright (c) 2024, Arm Limited.

Signed-off-by: Karl Meakin <[email protected]>
…iance#9267)

* Add a couple assertions about misuse of StructReturn

* Move STACK_ARG_RET_SIZE_LIMIT enforcement to SigSet::from_func_sig

* Slightly simplify SigSet::abi_sig_for_sig_ref

* Pass the return area pointer as first argument on sysv and fastcall

The SystemV and WindowsFastcall calling conventions expect the return
area pointer as first argument on most archs, while the Tail and Winch
calling conventions expect it as last argument on all archs. On arm64 x8
is used as return area pointer register. S390x already handled
everything correctly.

* Explicitly annotate call conv to use in s390x user_stack_maps test

* Fix windows_fastcall abi

* Improve Debug impls for Reg and ValueRegs
* Implement the `struct.*` GC instructions

This commit implements the `struct.*` instructions for the GC proposal.  These
instructions allow allocating new structs and getting and setting their
fields.

The implemented instructions are:

* `struct.new`
* `struct.new_default`
* `struct.get`
* `struct.get_s`
* `struct.get_u`
* `struct.set`

The `struct.new*` instructions are also allowed in constant expressions, but
support for that is not yet implemented.

Co-Authored-By: Trevor Elliott <[email protected]>

* Fill in TODO doc comment

* Dedupe gc-disabled messages

* Fix warnings in no-gc builds

---------

Co-authored-by: Trevor Elliott <[email protected]>
…e#9278)

* Make `gc_compiler` return a result

This way we don't even need to stub out a no-op GC compiler when GC is disabled
at compile time.

* Move DRC-specific GC compiler bits to its own submodule

This lets us differentiate between common code that is needed for any GC
compiler implementation and DRC-specific code.

* Stop manually forwarding proxying the GC compiler interface

Just `pub use imp::*` instead
)

* Rename the `wasmtime::runtime::vm::Store` trait to `VMStore`

Purely mechanical.

* Add `StoreOpaque` accessors to the `VMStore` trait

* Make `dyn VMStore` deref to `StoreOpaque`

* Remove the `VMStore::vmruntime_limits` method

* Remove the `VMStore::epoch_ptr` method

* Rename `VMStore::gc_store` to `unwrap_gc_store_mut`

Will make removing the trait method easier.

* Remove `VMStore`'s `GcStore`-related methods

* cargo fmt

* Fix build with shared memory disabled
The only thing it does over Context::compile is writing the machine code
to a Vec specified by the user. Every user of Context::compile_and_emit
in Cranelift didn't actually need ownership over the machine code bytes
and thus would have been able to use Context::compile instead to avoid
an unnecessary allocation. This commit moves all in-tree users of
compile_and_emit to compile and additionally to avoid other users adding
an unnecessary allocation as they though it to be necessary, this commit
additionally deprecates compile_and_emit.
The alignment for stackslots was commputed wrongly, because the
end of the slot was being aligned instead of the beginning.
This effectively meant that the _next_ stackslot was being aligned
on the alignment of the current slot.
…iance#9284)

* Remove unused isle_prelude_caller_methods macro argument

* Move gen_return_call into isle_prelude_caller_methods!

This reduces duplication between backends a bit.
Copyright (c) 2024, Arm Limited.

Signed-off-by: Karl Meakin <[email protected]>
With bytecodealliance#9266 Wasmtime should have full support for this platform. While
not tested in CI it can still be useful to build artifacts nonetheless
in case users are interested.

prtest:full
…C instructions (bytecodealliance#9282)

* Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions

* fix no-gc builds

* wrap const evaluation in `AutoAssertNoGc`

* add assertions that we access `VMGcRef`s in native-endian

* fix an endian mismatch bug between compiled wasm code and host code
* Introduce the `wasmtime::EqRef` type

This commit introduces the `wasmtime::EqRef` type, which corresponds to Wasm's
`(ref eq)` type, and statically represents Wasm references that can be tested
for equality.

* fix no-gc builds
…dealliance#9286)

* Remove the `wasmtime::runtime::vm::ModuleInfo` trait

This harkens back to the `wasmtime` vs `wasmtime-runtime` crate split. We can
simply use `wasmtime::Module` these days.

* Rename `wasmtime::runtime::vm::ModuleInfoLookup::lookup` to `lookup_module_by_pc`

This will make removing `ModuleInfoLookup` easier in subsequent commits.

* Remove the `ModuleInfoLookup` trait

This harkens back to the `wasmtime` vs `wasmtime-runtime` crate split. We can
simply use the `ModuleRegistry` directly now.

* cargo fmt
…ea ptr (bytecodealliance#9287)

* Make the Tail call conv follow the system call conv for the return area ptr

And for Winch make it follow the system call conv on all targets except
aarch64 where the first regular argument register is used instead of
the designated register.

* Fix review comments
…nce#9291)

* Update some dependencies on their major version tracks

Update some deps in our `Cargo.toml` from crates.io that were behind
their latest semver-compatible tracks. No major motivation at this time
other than keeping up-to-date.

* Fix compile on arm64 windows
…#9292)

This commit derives the operand size from `ABI::word_bytes()` in order
to zero the given register rather than hardcoding it as a 32-bit size
operand.

The motivation for this commit is mainly avoiding hardcoding operand
sizes in Winch's emission layer where possible, especially in the
MacroAssembler.
* Lower conditional traps in backend

Instead of legalizing `trapz` and `trapnz` in the mid-end, we now take them all
the way to the backend. This allows us to GVN them and remove redundant trap
checks. This also allows us to avoid creating new blocks in the legalizer and
otherwise invalidating the control-flow graph.

* Lower `trap[n]z` clif instructions in Pulley

* Update disas tests

---------

Co-authored-by: Nick Fitzgerald <[email protected]>
Helps deduplicate wasm-tools deps in the workspace.
saulecabrera and others added 10 commits September 24, 2024 15:29
This commit introduces a REAME.md in `winch`s directory with some
high-level documentation which was long overdue.
Winch on x64_64 can _almost_ be considered Tier 2, however we are still missing
support for some Tier 1 WebAssembly proposals.
To precisely match the Wasm spec tests, we would also need `NullStructRef` and
`NullArrayRef`, etc... This is not practical, given the encoding space we have
available. We are already matching expected "null FOO reference" trap messages
when running the spec tests to our own "null reference" messages, so we can do
that for `i31`s as well.
This is needed in the implementation of Wasm GC's array instructions.
…alliance#9288)

* feat: bindgen: add support for multiple wit paths

* expanded tests

* fmt

---------

Co-authored-by: Lochlan Wansbrough <>
…iance#9302)

* Add `-Wasync-stack-size`, automatically configure it too

Recently the `wasmtime` CLI switched from sync to async to handle
interrupting host APIs in WASI. Previously the CLI provided no means
to configure the async stack size, however, which now means that when
increasing the max wasm stack the CLI prints an error that cannot be
resolved about the wasm stack being larger than the async stack. This
commit fixes this issue by both adding a configuration option for the
async stack size and additionally automatically increasing the async
stack size when only the wasm stack size is provided.

Closes bytecodealliance#9298

* Fix feature-gated build
* Update to cap-std 3.3.0.

cap-std 3.3.0 contains bytecodealliance/cap-std#366, which fixes bytecodealliance#9272,
which is about the handling of `..` in symlink destinations.

* Add wildcard vet of pulley

---------

Co-authored-by: Alex Crichton <[email protected]>
@dhil
Copy link
Member Author

dhil commented Sep 25, 2024

@frank-emrich I am going to merge this even though the performance regression monitor reports failure. It probably shouldn't fail due to a regression but rather report it directly here on the PR as a comment. But we can look into building such a bot later.

@dhil dhil merged commit 05e3676 into wasmfx:main Sep 25, 2024
53 of 54 checks passed
@dhil dhil deleted the wasmfx-merge branch September 25, 2024 15:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.