Linking WebAssembly modules with an AssemblyScript package

[abrown]

I would like to understand whether it is possible (and if so, how) to compile an AssemblyScript project while linking in several already-compiled WebAssembly modules. If I understand how asc works, an easier scenario is possible: if we had multiple AssemblyScript projects published to NPM, we could depend on them in the package.json, import them in our AssemblyScript files, and asc will happily compile them all together into a single WebAssembly module. Is this correct?

But what if we want to link with a WebAssembly module compiled from C or Rust? The tool-conventions repository has some documentation on linking--will asc be able to use WebAssembly modules compiled with that convention to link everything together? Or will asc emit enough information for wasm-ld to be able to link all the modules together as a separate step? I've also looked at the --lib flag on asc and wondered if there was some way to use that to link everything together (indeed, if you could point me to an example using --lib it might help me understand it better!).

Thanks in advance for any thought put into this!

[abrown]

cc: @MaxGraey

[MaxGraey]

But what if we want to link with a WebAssembly module compiled from C or Rust?

Dynamic linking expecially with other langs not possible yet. It's WebAssebmly limitation. See this proposal: https://github.com/WebAssembly/module-linking/blob/master/proposals/module-linking/Explainer.md which still is not standardized and not supporting at the moment: https://webassembly.org/roadmap

The tool-conventions repository has some "documentation on linking"

It's Static Object File Linking which supports only in LLVM-based langs.

Or will asc emit enough information for wasm-ld to be able to link all the modules together as a separate step?

For working with wasm lld all langs should generate special linking section and shipped as object file which doesn't support by AS or any other non-LLVM-based compilers.

[dcodeIO]

To enable the several linking scenarios, I see the following possible paths:

• Tool conventions / static: Adding Wasm object file support to Binaryen (which is what AS uses instead of LLVM), producing the necessary relocation information for wasm-ld.
• Module Linking / dynamic: Wait for the proposal to progress and hope that it will eventually support AS as well.
• Other / dynamic: Utilize JavaScript or another host language to transfer (copy) values between modules using a custom scheme.

Note that --lib and --path merely add additional paths to library and user source files respectively.

[abrown]

For what it's worth, I think having just static linking would solve my original problem. And, thinking about it more, what I'm actually looking for isn't really relocation-aware linking as in the tool-conventions docs but rather a simplistic "match up the exports from this Wasm file with the imports from this other one and emit a single file." I guess this makes relocations a problem if they share a single memory but I had some vague notion that they could avoid this by using separate memories once that proposal is finalized. What do you think about this fourth approach: wait for multi-memory and then use named imports/exports to link? (I guess this wouldn't need to be an AS-specific tool; mostly thinking out loud here).

[abrown]

Looks like multi-memory is in phase 3 so perhaps this is not too crazy...

[MaxGraey]

With multi-memory proposal and shared-nothing approach it could works. Also, global variables will need to be renumbered, tables will need to be reassigned, and other sections will need to be separated somehow

[dcodeIO]

Makes me wonder how this would "just work" when the linked imports and exports pass pointers into their respective memories around. Seems like there'd still have to be marshalling whenever data pointed to moves between memories, quite similar to IT. Haven't thought about this approach in detail, yet, though.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in one week if no further activity occurs. Thank you for your contributions!