alexcrichton wrote: > So the core module + metadata is kind of isomorphic with that > single-core-module-component?
Sort of and sort of not. At a high level you're correct, but at a technical level this isn't correct. The subtle differences are: * Most wasm binaries today using WASI probably use `wasi_snapshot_preview1` imports. That means they need an "adapter" to switch to to WASIp2-based imports. That adapter is a core wasm which is currently baked into `wasm-component-ld` (see the adapters in [this folder](https://github.com/alexcrichton/wasm-component-ld/tree/main/src)) * Due to the way components and lifting and lowering works many imports need a "shim". For example in the component model when you "lower" a function from a component function to a core function you need to specify a linear memory. A linear memory isn't available until you instantiate the core module, but the core module needs the lowered imports to be instantiated. To break this cycle we introduce a shim wasm module which uses `call_indirect` through a table for its exports, so that's used to pass in as imports when instantiating the main module, and then after the main module is instantiated we instantiate another shim module that fills in the table. Going from core module + metadata into a component is a pretty nontrivial operation, so the raw output of `wasm-ld` (module + metadata) isn't suitable as an intermediate artifact for components. > I was more asking about whether the file types is accepts are anything more > than object files and libraries. i.e. can you pass other core modules and > have wasm-component-ld build a component that contains more than one core > module? Ah sory I misunderstood! Currently wasm-component-ld takes no other inputs and it assumes everything goes into `wasm-ld`. In the future for the dynamic linking case above it may start taking in `*.wasm` binaries compiled as shared libraries to bundle and/or refer to in the output component, but that's in the future. That means that at this time wasm-component-ld will always build a component with a single "main module", e.g. the one from `wasm-ld`. > Also, can you say more about the metadata that is being using to drive > wasm-componenet-ld? If the core module is all based on canonical ABI what > extra metdata is needed/planned? Certainly! The canonical ABI gives the ability to say that for any component model function type it corresponds to a particular core wasm function type. That operation is not reversible, though, you can't go from core wasm back to the component model function type. Thus the metadata carries along this information. That way the componentization process draws a mapping from component model import/export to core wasm import/export and then can synthesize the right type in the component binary format. The short answer to your question, though, is `wasm-tools component wit ./my-wit-files --wasm`. That output blob, which is itself a component but only with type information, is embedded in core wasm. Put another way we start with WIT files, then those are converted into their binary format as a component with only types, that gets fed through LLVM/wasm-ld, then on the other end we deserialize the component-with-type-information, turn it back into WIT, and then make the real component. https://github.com/llvm/llvm-project/pull/84569 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
