See https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/readytorun-overview.md and https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/readytorun-format.md

In order to deliver managed code as pre-compiled Wasm we need an updated version of the ReadyToRun (R2R) compiler and VM-side implementation. This depends on features like the object writer.

We likely want to run R2R in "composite mode" where the code for a whole graph of assemblies is all generated as one unit, instead of individually for each module.

Storage considerations

Ideally we would store R2R tables and other metadata in a Wasm custom section, but the only way to access the contents of a custom section is via a JS host API which copies the data into an arraybuffer. So we probably need to store them all in the data section, either as constant data that is automatically loaded into memory when the module is instantiated, or as passive data segments that we can load into memory at a given offset using the memory.init opcode.

Linking considerations

If we plan to link all our Wasm into a single file alongside the runtime, any tables and metadata we generate need to also have associated relocations.

Format considerations

Some parts of the R2R format make PE-specific/CLI-specific assumptions, for example:

CLI Header ManagedNativeHeader points to READYTORUN_HEADER

The design will need to be updated/extended to be representable in Wasm. For example in the above case we could make this work by embedding an entire PE file into a Wasm wrapper like WebCIL does, and having all the R2R tables and other metadata live inside this wrapped PE file.

Any parts of the format that refer to method RVAs will need to instead contain Wasm function pointers, which will need an associated relocation for linking.

(incomplete - work in progress)