[RyuJIT Wasm] Add Object Writer Imports Section + Constant Exprs to Encode R2R Payload Placement

[adamperlin]

This PR adds support for generating an import section to the WasmObjectWriter. We currently import:

• env.memory
• __stack_pointer
• __r2r_start
  Which are all expected to be provided by the runtime. Various data segments are then placed into __r2r_start + <segment_offset>. We use the constant expressions extension for these address calculations.

Notably this PR removes our export of the module memory, as we want to share memory with the runtime.

[kg]

I will try and update the test harness to be compatible with this

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[adamperlin]

@kg I'd love a review on this when you have a chance!

[Copilot]

Pull request overview

Adds initial support for emitting a Wasm import section from WasmObjectWriter, and switches R2R data segment placement to use constant expressions based on an imported __r2r_start symbol.

Changes:

• Introduces a new wasm.import object node section and emits it as Wasm section type Import.
• Reworks combined data segment placement to use an instruction expression (global.get __r2r_start + i32.const offset + i32.add) instead of a fixed DataStartOffset.
• Adds a small Wasm encoding model (imports, globals, memory type, expression/instruction encoding) and a helper to write UTF-8 strings with a length prefix.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 7 comments.

File	Description
src/coreclr/tools/Common/Compiler/ObjectWriter/WasmObjectWriter.cs	Adds import section emission and uses __r2r_start + offset constant expressions for data segment placement.
src/coreclr/tools/Common/Compiler/ObjectWriter/WasmNative.cs	Adds encodable abstractions/types for Wasm expressions and import encodings (memory/global types, etc.).
src/coreclr/tools/Common/Compiler/ObjectWriter/SectionWriter.cs	Adds WriteUtf8WithLength helper for Wasm-style length-prefixed strings.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[kg]

This looks fairly good, all of Copilot's feedback seemed accurate though so we need to address it.
The Encode/EncodeSize split is a little awkward but I don't see an obvious way to get rid of it other than doing something weird with empty spans.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[adamperlin]

This looks fairly good, all of Copilot's feedback seemed accurate though so we need to address it. The Encode/EncodeSize split is a little awkward but I don't see an obvious way to get rid of it other than doing something weird with empty spans.

Agreed, I'd prefer to get rid of that split if we can find a clean way to do it. Copilot already caught a bug introduced because of this. Honestly, a solution using empty spans to calculate the exact length before writing might be preferrable for ensuring correctness.

I think I'll address this as a refactor in a follow up. My thinking here is to create a lightweight wrapper type that can be consumed as a ref struct by all the Encode methods instead of consuming the spans directly, which is capable of either counting bytes that would be written or writing into a target span depending on if its internal span is empty or not.

[adamperlin]

@kg This should be ready for another look when you have a moment!

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.

[adamperlin]

/ba-g unrelated failures