You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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::Module will 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 Resolver for 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)
Open questions:
What should wasm2obj do for multi-module wasm files?
What should the runtime representation in wasmtime-jit be for imported instances and imported modules?
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:
Implementation Notes
Some miscenalleous notes on the implementation and how this is being implemented:
wasmtime::Modulewill internally have a list of modules to select from.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".Open questions:
wasm2objdo for multi-module wasm files?wasmtime-jitbe for imported instances and imported modules?