wasmtime / Issue #2094 Implement the module linking propo... · git-wasmtime · Zulip Chat Archive

Stream: git-wasmtime

Topic: wasmtime / Issue #2094 Implement the module linking propo...

Wasmtime GitHub notifications bot (Aug 04 2020 at 19:21):

alexcrichton opened Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[ ] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[ ] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[ ] Implement the alias section

[ ] Implement the instance section

[ ] Implement module export/import

[ ] Implement instance export/import

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Aug 04 2020 at 19:21):

alexcrichton labeled Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[ ] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[ ] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[ ] Implement the alias section

[ ] Implement the instance section

[ ] Implement module export/import

[ ] Implement instance export/import

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Nov 04 2020 at 16:22):

tschneidereit commented on Issue #2094:

Update wasmparser used by Wasmtime to understand module linking

It seems like this is done?

Wasmtime GitHub notifications bot (Nov 04 2020 at 16:24):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[ ] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[ ] Implement the alias section

[ ] Implement the instance section

[ ] Implement module export/import

[ ] Implement instance export/import

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Nov 04 2020 at 16:24):

alexcrichton commented on Issue #2094:

Indeed!

Wasmtime GitHub notifications bot (Nov 23 2020 at 18:28):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[ ] Implement the alias section

[ ] Implement the instance section

[ ] Implement module export/import

[ ] Implement instance export/import

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Nov 23 2020 at 23:32):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[ ] Implement the alias section

[ ] Implement the instance section #2447

[ ] Implement module export/import

[ ] Implement instance export/import

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Nov 25 2020 at 16:58):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[ ] Implement the alias section #2451

[ ] Implement the instance section #2447

[ ] Implement module export/import

[ ] Implement instance export/import

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Dec 01 2020 at 22:58):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[ ] Implement the alias section #2451

[x] Implement the instance section #2447

[ ] Implement module export/import #2461

[ ] Implement instance export/import #2461

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Dec 03 2020 at 02:48):

peterhuene edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[ ] Implement module export/import #2461

[ ] Implement instance export/import #2461

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Dec 03 2020 at 16:18):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[ ] Implement instance export/import #2461

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Dec 03 2020 at 16:19):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[x] Implement instance export/import #2461

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Dec 03 2020 at 19:21):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[x] Implement instance export/import #2461

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API #2472

[ ] Implement module linking for one of wasmtime-{go,dotnet,py}

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::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?

Wasmtime GitHub notifications bot (Dec 03 2020 at 19:23):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[x] Implement instance export/import #2461

[ ] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API #2472

[ ] Implement module linking for one of wasmtime-{go,dotnet,py} https://github.com/bytecodealliance/wasmtime-py/pull/47

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::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?

Wasmtime GitHub notifications bot (Dec 03 2020 at 19:51):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[x] Implement instance export/import #2461

[x] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API #2472

[ ] Implement module linking for one of wasmtime-{go,dotnet,py} https://github.com/bytecodealliance/wasmtime-py/pull/47

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::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?

Wasmtime GitHub notifications bot (Dec 03 2020 at 19:52):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[x] Implement instance export/import #2461

[x] Ensure the Rust API exposes module linking well

[ ] Implement module linking in the C API #2472

[ ] Implement module linking for one of wasmtime-{go,dotnet,py} https://github.com/bytecodealliance/wasmtime-py/pull/47

[ ] 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::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?

Wasmtime GitHub notifications bot (Dec 03 2020 at 21:51):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[x] Implement instance export/import #2461

[x] Ensure the Rust API exposes module linking well

[x] Implement module linking in the C API #2472

[ ] Implement module linking for one of wasmtime-{go,dotnet,py} https://github.com/bytecodealliance/wasmtime-py/pull/47

[ ] 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::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?

Wasmtime GitHub notifications bot (Dec 03 2020 at 21:51):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[x] Implement instance export/import #2461

[x] Ensure the Rust API exposes module linking well

[x] Implement module linking in the C API #2472

[x] Implement module linking for one of wasmtime-{go,dotnet,py} https://github.com/bytecodealliance/wasmtime-py/pull/47

[ ] 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::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?

Wasmtime GitHub notifications bot (Dec 03 2020 at 23:04):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[x] Implement instance export/import #2461

[x] Ensure the Rust API exposes module linking well

[x] Implement module linking in the C API #2472

[x] Implement module linking for one of wasmtime-{go,dotnet,py} https://github.com/bytecodealliance/wasmtime-py/pull/47, https://github.com/bytecodealliance/wasmtime-go/pull/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::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?

Wasmtime GitHub notifications bot (Dec 18 2020 at 17:15):

alexcrichton edited Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[x] Implement instance export/import #2461

[x] Ensure the Rust API exposes module linking well

[x] Implement module linking in the C API #2472

[x] Implement module linking for one of wasmtime-{go,dotnet,py} https://github.com/bytecodealliance/wasmtime-py/pull/47, https://github.com/bytecodealliance/wasmtime-go/pull/46

[x] 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::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?

Wasmtime GitHub notifications bot (Dec 18 2020 at 17:15):

alexcrichton commented on Issue #2094:

Ok this is all done now so I'm going to close this. I'm still wading through fuzz bugs at this point but the bulk of it is all there!

Wasmtime GitHub notifications bot (Dec 18 2020 at 17:15):

alexcrichton closed Issue #2094:

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:

[x] Implement in wasm-tools (validation, text, binary, etc) https://github.com/bytecodealliance/wasm-tools/pull/26, https://github.com/bytecodealliance/wasm-tools/pull/30, https://github.com/bytecodealliance/wasm-tools/pull/38, https://github.com/bytecodealliance/wasm-tools/pull/40, ...

[x] Update wasmparser used by Wasmtime to understand module linking https://github.com/bytecodealliance/wasmtime/pull/2059

[x] Initial groundwork for compiling many modules at once https://github.com/bytecodealliance/wasmtime/pull/2093

[x] Implement the alias section #2451

[x] Implement the instance section #2447

[x] Implement module export/import #2461

[x] Implement instance export/import #2461

[x] Ensure the Rust API exposes module linking well

[x] Implement module linking in the C API #2472

[x] Implement module linking for one of wasmtime-{go,dotnet,py} https://github.com/bytecodealliance/wasmtime-py/pull/47, https://github.com/bytecodealliance/wasmtime-go/pull/46

[x] 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::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?

Last updated: Dec 23 2024 at 12:05 UTC