-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Closed
Labels
wasmtimeIssues about wasmtime that don't fall into another labelIssues about wasmtime that don't fall into another label
Description
I plan to use this as a tracking issue for the module linking proposal in Wasmtime. I'll be updating this description over time as I find time and as work is done:
- Implement in wasm-tools (validation, text, binary, etc) Initial implementation of module linking wasm-tools#26, wasmpaser: Validate nested modules wasm-tools#30, Disallow module linking sections by default wasm-tools#38, Rewrite wasmparser's module parser and validator wasm-tools#40, ...
- Update wasmparser used by Wasmtime to understand module linking Validate modules while translating #2059
- Initial groundwork for compiling many modules at once Start compiling module-linking modules #2093
- Implement the alias section Implement the module linking alias section #2451
- Implement the instance section Instantiate nested modules for module linking #2447
- Implement module export/import Implement imported/exported modules/instances #2461
- Implement instance export/import Implement imported/exported modules/instances #2461
- Ensure the Rust API exposes module linking well
- Implement module linking in the C API Update the C API with module linking support #2472
- Implement module linking for one of wasmtime-{go,dotnet,py} Add support for the module linking proposal wasmtime-py#47, Implement module linking proposal wasmtime-go#46
- Implement fuzzing for module linking
Implementation Notes
Some miscenalleous notes on the implementation and how this is being implemented:
- Per-module data structures are intended to continue to be per-module, only
wasmtime::Modulewill internally have a list of modules to select from. - Aliases are expected to be implemented under the hood as imports.
- It's expected that instantiation will pass in a
Resolverfor the actual imports, as well as the "surrounding environment" which is probably "the list of all other modules that came from the original wasm file". - JIT code will call an aliased function from an imported instance as if it were an imported function. (similar for tables/globals/etc)
- It's expected that instantiation will pass in a
Open questions:
- What should
wasm2objdo for multi-module wasm files? - What should the runtime representation in
wasmtime-jitbe for imported instances and imported modules?
daubaris, repi, AdrianGjerstad and eminence
Metadata
Metadata
Assignees
Labels
wasmtimeIssues about wasmtime that don't fall into another labelIssues about wasmtime that don't fall into another label