History log of /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/debug_builtins.rs (Results 1 – 13 of 13)
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
# 900370bc 21-Aug-2025 Alex Crichton <[email protected]>

Make core wasm libcalls sound (#11496)

* Make core wasm libcalls sound

This commit updates the signature of core wasm libcalls to look more
like component libcalls where the instance argument is ju

Make core wasm libcalls sound (#11496)

* Make core wasm libcalls sound

This commit updates the signature of core wasm libcalls to look more
like component libcalls where the instance argument is just an id, not
an actual pointer. This is required to make them sound because otherwise
it's possible to, in safe Rust, acquire two mutable pointers to the same
instance. Implementing this change is made possible by the many many
previous refactors to how all of these internals work. All that was
required here was changing type signatures and minor updates to the
order of operations inside of libcalls.

Closes #11178

* Fix wmemcheck build

show more ...


Revision tags: v36.0.1, v36.0.0
# 82941262 18-Aug-2025 Alex Crichton <[email protected]>

Require a store in `catch_unwind_and_record_trap` (#11441)

* Require a store in `catch_unwind_and_record_trap`

This commit does some preparatory refactoring for #11326 to ensure that
a store is ava

Require a store in `catch_unwind_and_record_trap` (#11441)

* Require a store in `catch_unwind_and_record_trap`

This commit does some preparatory refactoring for #11326 to ensure that
a store is available when trap information is being processed. Currently
this doesn't leverage the new parameter but it should be leverage-able
in #11326.

* Review comments

show more ...


# 74efac71 29-Jul-2025 Doru Blânzeanu <[email protected]>

Allow compiling debug-builtins in no_std environment to enable gdb jit (#11304)

* Allow compiling debug-builtins in no_std environment to enable gdb jit

- Make jit-debug crate #![no_std] when `std`

Allow compiling debug-builtins in no_std environment to enable gdb jit (#11304)

* Allow compiling debug-builtins in no_std environment to enable gdb jit

- Make jit-debug crate #![no_std] when `std` feature is not enabled
- Make gdb_jit_int module build in no_std environment
- Use std when perf_jitdebug is enabled because the perf_jitdebug module
does not run in no_std environment
- Change debug-builtins feature to only enable gdb_jit_int
- The perf_jitdebug feature is enabled in profiling mode only

Signed-off-by: Doru Blânzeanu <[email protected]>

* Remove feature listing from `default`

These are otherwise present via `std`.

* Shuffle around some features

* Enable `wasmtime-jit-debug/std` from wasmtime's `std` feature
* Only enable `perf_jitdump` from `profiling` as that's all that's
explicitly needed.

* Remove empty features list

* Cut down on some `#[cfg]` usage

* Update comments in gdb_jit_int module

* Add CI checks that `debug-builtins` builds on no_std

* Fix missing has_host_compiler_backend when debug-builtins enabled

Signed-off-by: Doru Blânzeanu <[email protected]>

---------

Signed-off-by: Doru Blânzeanu <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>

show more ...


# 35786823 23-Jul-2025 Alex Crichton <[email protected]>

Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm` (#11312)

* Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm`

Slowly expanding this lint to more of the crate.

prtest:full

* Fix lin

Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm` (#11312)

* Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm`

Slowly expanding this lint to more of the crate.

prtest:full

* Fix lints in custom module

* Fix some lints with miri

* Fix non-VM build

* Fix arm windows

show more ...


Revision tags: v35.0.0, v24.0.4, v33.0.2, v34.0.2
# f021346e 17-Jul-2025 Alex Crichton <[email protected]>

More table safety improvements (#11255)

* More table safety improvements

This is some more progress on #11179 aimed at improving the safety of
management of tables internally within Wasmtime:

* `I

More table safety improvements (#11255)

* More table safety improvements

This is some more progress on #11179 aimed at improving the safety of
management of tables internally within Wasmtime:

* `Instance::table_index` is removed as it can be replaced with data
stored directly in the `VMTableImport` now.
* `Instance::get_table` now returns `&mut Table`
* `Instance::get_defined_table_with_lazy_init` now returns `&mut Table`
* `Instance::with_defined_table_index_and_instance` now directly returns
`DefinedTableIndex` plus `Pin<&mut Instance>`, codifying the ability
to "laterally move" between instances.
* `Instance::table_init_segment` was refactored to "take" the tables
during initialization and replace them afterwards, resolving the split
borrow issue and removing an `unsafe` block in the function.

cc #11179

* Improve safety of `Table::copy`

This commit fixes an issue in the previous commit with respect to Miri
and Stacked Borrows. This does so by improving the safety of the
`Table::copy`-related functions to all work mostly on safe code rather
than unsafe references. Some minor amount of unsafety is still present
but it is now clearly documented and easier to verify.

* Fix tests

show more ...


# e16780de 30-Jun-2025 fuder.eth <[email protected]>

fix typos in Runtime VM Source Files (#11158)

* Update debug_builtins.rs

* Update libcalls.rs

* Update stack_switching.rs


Revision tags: 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
# b86b9682 23-Jan-2025 Alex Crichton <[email protected]>

Provenance preparation for Pulley (#10043)

* Provenance preparation for Pulley

This commit is an internal refactoring of Wasmtime's runtime to prepare
to execute Pulley in MIRI. Currently today th

Provenance preparation for Pulley (#10043)

* Provenance preparation for Pulley

This commit is an internal refactoring of Wasmtime's runtime to prepare
to execute Pulley in MIRI. Currently today this is not possible because
Pulley does not properly respect either strict or permissive provenance
models. The goal of this refactoring is to enable fixing this in a
future commit that doesn't touch everything in the codebase. Instead
everything is touched here in this commit.

The basic problem with Pulley is that it is incompatible with the strict
provenance model of Rust which means that we'll be using "exposed
provenance" APIs to satisfy Rust's soundness requirements. In this model
we must explicitly call `ptr.expose_provenance()` on any pointers
which are exposed to compiled code. Arguably we should also be already
doing this for natively-compiled code but I am not certain about how
strictly this is required.

Currently in Wasmtime today we call `ptr.expose_provenance()` nowhere.
It also turns out, though, that we share quite a few pointers in quite a
few places with compiled code. This creates a bit of a problem! The
solution settled on in this commit looks like:

* A new marker trait, `VmSafe`, is introduced. This trait is used to
represent "safe to share with compiled code" types and enumerates some
properties such as defined ABIs, primitives wrappers match primitive
ABIs, and notably "does not contain a pointer".

* A new type, `VmPtr<T>`, is added to represent pointers shared with
compiled code. Internally for now this is just `SendSyncPtr<T>` but in
the future it will be `usize`. By using `SendSyncPtr<T>` it shouldn't
actually really change anything today other than requiring a lot of
refactoring to get the types to line up.

* The core `vmctx_plus_offset*` methods are updated to require
`T: VmSafe`. Previously they allowed any `T` which is relatively
dangerous to store any possible Rust type in Cranelift-accessible
areas.

These three fundamental changes were introduced in this commit. All
further changes were refactoring necessary to get everything working
after these changes. For example many types in `vmcontext.rs`, such as
`VMFuncRef`, have changed to using `VmPtr<T>` instead of `NonNull<T>` or
`*mut T`. This is a pretty expansive change which resulted in touching a
lot of places.

One premise of `VmPtr<T>` is that it's non-null. This was an
additional refactoring that updated a lot of places where previously
`*mut T` was used and now either `VmPtr<T>` or `NonNull<T>` is used.

In the end the intention is that `VmPtr<T>` is used whenever pointers
are store in memory that can be accessed from Cranelift. When operating
inside of the runtime `NonNull<T>` or `SendSyncPtr<T>` is preferred
instead.

As a final note, no provenance changes have actually happened yet. For
example this doesn't fix Pulley in MIRI. What it does enable, though, is
that the future commit to fix Pulley in MIRI will be much smaller with
this having already landed.

* Run the full test suite in PR CI

prtest:full

* Minor CI issues

* Fix no_std build

* Fix miri build

* Don't use `VmPtr` in FFI function signatures

Use `NonNull` or `*mut u8` as appropriate for function signatures
instead. It shouldn't be required to use `VmPtr` during the handoff to
compiled code as we've already annotated the pointer going out.

* Fix rebase conflict

* Review comments

show more ...


Revision tags: v29.0.1, v29.0.0, v28.0.1
# 0fff9c10 09-Jan-2025 Alex Crichton <[email protected]>

Enable `missing-unsafe-on-extern` lint (#9963)

* Enable `missing-unsafe-on-extern` lint

This'll be a hard error in the 2024 edition so go ahead and opt-in to it
now to ease our future transition.

Enable `missing-unsafe-on-extern` lint (#9963)

* Enable `missing-unsafe-on-extern` lint

This'll be a hard error in the 2024 edition so go ahead and opt-in to it
now to ease our future transition.

* Fix adapter build

* Fix custom c-api build

* Fix fuzzer build

* Fix some Windows `extern` blocks

show more ...


# 115da98d 07-Jan-2025 Alex Crichton <[email protected]>

Move gdbjit C helpers to a separate file (#9939)

* Move gdbjit C helpers to a separate file

This commit splits out the gdbjit-related helpers from `helpers.c` in
Wasmtime to a separate C file built

Move gdbjit C helpers to a separate file (#9939)

* Move gdbjit C helpers to a separate file

This commit splits out the gdbjit-related helpers from `helpers.c` in
Wasmtime to a separate C file built as part of the `wasmtime-jit-debug`
crate. This'll help excise these helpers if gdbjit support is disabled
at compile time and additionally brings them closer to the actual
definition in the `wasmtime-jit-debug` crate.

* Fix linkage issues

* Fix miri tests

show more ...


Revision tags: v28.0.0
# 8e4f0cd3 02-Dec-2024 SingleAccretion <[email protected]>

Export debug builtins on Windows (#9706)

This allows the debugger to find them.

After much research, this has been chosen as the overall best solution.
The alternative here would be to create machi

Export debug builtins on Windows (#9706)

This allows the debugger to find them.

After much research, this has been chosen as the overall best solution.
The alternative here would be to create machine code thunks that call
these symbols when Jitting code, and describing those thunks in DWARF,
which would be significantly more complex.

show more ...


Revision tags: v27.0.0, v26.0.1, v25.0.3, v24.0.2
# 2a7f0653 31-Oct-2024 Alex Crichton <[email protected]>

Remove the `wasmtime_environ::MemoryPlan` type (#9532)

* Remove the `wasmtime_environ::MemoryPlan` type

This is the equivalent of #9530 for memories. The goal of this commit is
to eventually remove

Remove the `wasmtime_environ::MemoryPlan` type (#9532)

* Remove the `wasmtime_environ::MemoryPlan` type

This is the equivalent of #9530 for memories. The goal of this commit is
to eventually remove the abstraction layer of `MemoryPlan` and
`MemoryStyle` in favor of directly reading the configuration of
`Tunables`. The prediction is that it will be simpler to work directly
with configured values instead of a layer of abstraction between the
configuration and the runtime which needs to be evolved independently to
capture how to interpret the configuration.

Like with #9530 my plan is to eventually remove the `MemoryStyle` type
itself, but that'll be a larger change, so it's deferred to a future
PR.

* Fix shared memory disabled build

show more ...


Revision tags: v26.0.0, v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1, v25.0.1, v25.0.0
# 2bdae8b6 16-Sep-2024 Nick Fitzgerald <[email protected]>

Rename the `wasmtime::runtime::vm::Instance::module` method to `env_module` (#9261)

Because it returns the `wasmtime_environ::Module`.

This paves the way for a new method to get the `wasmtime::Modu

Rename the `wasmtime::runtime::vm::Instance::module` method to `env_module` (#9261)

Because it returns the `wasmtime_environ::Module`.

This paves the way for a new method to get the `wasmtime::Module`.

show more ...


Revision tags: v24.0.0, v23.0.2, v23.0.1, v23.0.0, v22.0.0, v21.0.1, v21.0.0, v20.0.2, v20.0.1
# 72004aad 30-Apr-2024 Nick Fitzgerald <[email protected]>

Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)

* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate

* Rewrite uses of `wasmtime

Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)

* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate

* Rewrite uses of `wasmtime_runtime` to `crate::runtime::vm`

* Remove dep on `wasmtime-runtime` from `wasmtime-cli`

* Move the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module

* Update labeler for merged crates

* Fix `publish verify`

prtest:full

show more ...