Changes in export.rs

2326d655 - Debugging: provide access to private (non-exported) entities. (#12367)

Wed, 21 Jan 2026 17:00:31 +0000

Debugging: provide access to private (non-exported) entities. (#12367)* Debugging: provide access to private (non-exported) entities.A debugger will need to access all entities (globals, tables, memories),even those that are not exported, in order to provide a full debuggingexperience: for example, a developer who has a debugger attached to aWasm component will expect to be able to see data in its memory.Historically we have been very careful in Wasmtime to provide access toWasm instances' entities only as the Wasm type system allows -- that is,only if they are exported. However, debugging is privileged -- in thesame way that a native host debugger has `ptrace` and can vieweverything about the debuggee, we need to provide APIs for seeingthrough the encapsulation boundary.To ensure that this "violation of encapsulation" is scoped only to theextent needed for the legitimate need (debugging), this API isdynamically available only when `guest_debug` is configured true for agiven engine. Otherwise, the accessor returns `None`.I opted not to provide a full introspection API that enumerates all ofthe entities as the debugger should already have access to the debuggeemodule and be able to enumerate the entities. Thus, the API onlyprovides a host-API handle when asking for an entity by index in a giveninstance's index space.* Review feedback.* Fix tests on 32-bit build (where threads and thus shared memory are not supported) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

1fcd0933 - Prevent using shared memories with `Memory` (#12022)

Tue, 11 Nov 2025 18:06:22 +0000

Prevent using shared memories with `Memory` (#12022)* Prevent using shared memories with `Memory`This commit fixes a few issues where it was possible to represent a wasmshared linear memory with the `wasmtime::Memory` type. This is not soundbecause `wasmtime::Memory` provides safe Rust access to the bytes wherethat is not possible with wasm shared memories. Shared memories in Rustmust be represented by `SharedMemory`, not `wasmtime::Memory`.Specifically this commit prevents two vectors of this happening:1. `Memory::new` now requires that the memory type specified is non-shared. Instead `SharedMemory::new` must be used instead.2. Core dumps now skip over shared memories when iterating over all memories in the store. Supporting shared memories is left to a future feature request for now.* CI fixes List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

2b832281 - Gut `vm::Export` to mostly be `crate::Extern` (#11229)

Mon, 14 Jul 2025 21:05:01 +0000

Gut `vm::Export` to mostly be `crate::Extern` (#11229)* Remove `Table::from_wasmtime_table`This commit removes the unsafe function `Table::from_wasmtime_table`.This goes a bit further and removes `ExportTable` entirely as well whichmeans that table lookup on a `vm::Instance` directly returns a`wasmtime::Table` without any need to translate back-and-forth.* Remove `Tag::from_wasmtime_tag`Like the previous commit, but for tags.* Remove `Global::from_wasmtime_global`Like the previous commit, but for globals.* Remove `Memory::from_wasmtime_memory`Like the previous commit, but for memories.* Remove `Func::from_wasmtime_function`Like previous commits, but for functions.* Fix lints* Fill out missing safety comment* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

c4fd2f7b - Refactor globals to no longer use `Stored` (#10902)

Mon, 02 Jun 2025 23:23:47 +0000

Refactor globals to no longer use `Stored` (#10902)This commit refactors the `wasmtime::Global` to avoid the usage of`Stored` internally. This makes conversion from internal global stateto external global state a noop along the lines of previous commits. Theend goal is to remove `Stored` entirely and enable more pervasively usingexternal types internally within Wasmtime as well.Globals were different than the prior iterations of memories, tags, andtables. Globals have three different ways of defining them: wasminstances, the host embedder, and component flags. Representing thesein all the various locations required a bit of finesse in how everythingis represented and stored at rest and such. In the end there's a smallamount of "type punning" in a few instance/vmctx fields related toglobals now since everything is squeezed into one slot. This is requiredbecause the `VMGlobalImport` structure must have a size known towasm-compiled code and `wasmtime::Global` must have a known layout for Ccode.In the end while this is more code to manage globals my hope is that theend result will be a net negative in terms of complexity by ensuringthat the embedder API is additionally suitable for use internally withinWasmtime as well. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

46306693 - Add a `DefinedTableIndex` to table imports/exports (#10879)

Mon, 02 Jun 2025 20:55:10 +0000

Add a `DefinedTableIndex` to table imports/exports (#10879)This commit extends `ExportTable` and `VMTableImport` (renamed from`VMTable`) to include a `DefinedTableIndex` in the same manner thatmemories carry their index they're defined at as well. The main goal ofthis change is to power the next change which will update how tables arestored in a store. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

598562bd - Add `VMContext` and `DefinedTagIndex` fields to tag-related imports/exports (#10882)

Mon, 02 Jun 2025 18:50:21 +0000

Add `VMContext` and `DefinedTagIndex` fields to tag-related imports/exports (#10882)* Add `VMContext` and `DefinedTagIndex` fields to tag-related imports/exportsSimilar to memories/tables, will be used in the next commit.* Fix VMOffsets size of tag List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

0b4c754a - Exception and control tags (#10251)

Thu, 20 Feb 2025 15:49:20 +0000

Exception and control tags (#10251)* Tags* Tag tests* Tests* Refer to tags issue* Engine index* Simplify* Fix clippy warnings List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

b86b9682 - Provenance preparation for Pulley (#10043)

Thu, 23 Jan 2025 20:55:28 +0000

Provenance preparation for Pulley (#10043)* Provenance preparation for PulleyThis commit is an internal refactoring of Wasmtime's runtime to prepareto execute Pulley in MIRI. Currently today this is not possible becausePulley does not properly respect either strict or permissive provenancemodels. The goal of this refactoring is to enable fixing this in afuture commit that doesn't touch everything in the codebase. Insteadeverything is touched here in this commit.The basic problem with Pulley is that it is incompatible with the strictprovenance model of Rust which means that we'll be using "exposedprovenance" APIs to satisfy Rust's soundness requirements. In this modelwe must explicitly call `ptr.expose_provenance()` on any pointerswhich are exposed to compiled code. Arguably we should also be alreadydoing this for natively-compiled code but I am not certain about howstrictly 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 afew places with compiled code. This creates a bit of a problem! Thesolution 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`, is added to represent pointers shared with compiled code. Internally for now this is just `SendSyncPtr` but in the future it will be `usize`. By using `SendSyncPtr` 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. Allfurther changes were refactoring necessary to get everything workingafter these changes. For example many types in `vmcontext.rs`, such as`VMFuncRef`, have changed to using `VmPtr` instead of `NonNull` or`*mut T`. This is a pretty expansive change which resulted in touching alot of places.One premise of `VmPtr` is that it's non-null. This was anadditional refactoring that updated a lot of places where previously`*mut T` was used and now either `VmPtr` or `NonNull` is used.In the end the intention is that `VmPtr` is used whenever pointersare store in memory that can be accessed from Cranelift. When operatinginside of the runtime `NonNull` or `SendSyncPtr` is preferredinstead.As a final note, no provenance changes have actually happened yet. Forexample this doesn't fix Pulley in MIRI. What it does enable, though, isthat the future commit to fix Pulley in MIRI will be much smaller withthis having already landed.* Run the full test suite in PR CIprtest:full* Minor CI issues* Fix no_std build* Fix miri build* Don't use `VmPtr` in FFI function signaturesUse `NonNull` or `*mut u8` as appropriate for function signaturesinstead. It shouldn't be required to use `VmPtr` during the handoff tocompiled code as we've already annotated the pointer going out.* Fix rebase conflict* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

2a7f0653 - Remove the `wasmtime_environ::MemoryPlan` type (#9532)

Thu, 31 Oct 2024 20:46:03 +0000

Remove the `wasmtime_environ::MemoryPlan` type (#9532)* Remove the `wasmtime_environ::MemoryPlan` typeThis is the equivalent of #9530 for memories. The goal of this commit isto 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 directlywith configured values instead of a layer of abstraction between theconfiguration and the runtime which needs to be evolved independently tocapture how to interpret the configuration.Like with #9530 my plan is to eventually remove the `MemoryStyle` typeitself, but that'll be a larger change, so it's deferred to a futurePR.* Fix shared memory disabled build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

7a49e44f - Remove the `wasmtime_environ::TablePlan` type (#9530)

Thu, 31 Oct 2024 17:05:54 +0000

Remove the `wasmtime_environ::TablePlan` type (#9530)* Remove the `wasmtime_environ::TablePlan` typeIn my quest to simplify memory configuration and how things workinternally in Wasmtime one thing I've identified to accomplish is theremoval of the `TablePlan` and `MemoryPlan` types. These introduce anabstraction layer between table/memory implementations and `Tunables`and personally I find it simpler to directly reference `Tunables` anduse that instead. The goal of this commit is to plumb `Tunables` closerto where it's directly read by removing the "indirection" through the`*Plan` types.The `TablePlan` and `MemoryPlan` types are pervasively used throughoutWasmtime so instead of having one large commit delete everything this isinstead a piecemeal approach to incrementally get towards the goal ofremoval. Here just `TablePlan` is removed and `Tunables` is plumbed in afew more places. I plan to also in the future remove `TableStyle` and`MemoryStyle` in favor of directly reading `Tunables` but that's leftfor a future commit. For now `TableStyle` persists and its usage is abit odd in isolation but I plan to follow this up with the removal of`TableStyle`.* Fix non-component-model build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

0e9121da - Fix some typos (#8641)

Thu, 16 May 2024 23:21:22 +0000

Fix some typos (#8641)* occurred* winch typos* tests typos* cli typos* fuzz typos* examples typos* docs typos* crates/wasmtime typos* crates/environ typos* crates/cranelift typos* crates/test-programs typos* crates/c-api typos* crates/cache typos* crates other typos* cranelift/codegen/src/isa typos* cranelift/codegen/src other typos* cranelift/codegen other typos* cranelift other typos* ci js typo* .github workflows typo* RELEASES typo* Fix clang-format documentation line---------Co-authored-by: Andrew Brown List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

81a89169 - Add support for `#![no_std]` to the `wasmtime` crate (#8533)

Sat, 04 May 2024 22:02:26 +0000

Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime's platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren't implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime's TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the "custom" platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can't be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely 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 thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime's `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest: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 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs

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

Tue, 30 Apr 2024 18:52:45 +0000

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 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/export.rs