[wasm] R2R: 32-byte struct passed by value is corrupted (fields shifted by one word)

[pavelsavara]

Description

On browser-wasm (CoreCLR) with PublishReadyToRun, a 32-byte struct (four 8-byte fields) passed by value to a method is corrupted: the callee reads it shifted up by one 8-byte word, so each field takes the value of the next and the following argument bleeds in. 16- and 24-byte structs pass correctly.

Repro

using System;

struct S32 { public long A, B, C, D; }

class Program
{
    static string E32(int x, S32 s, int y) => $"{x}|{s.A},{s.B},{s.C},{s.D}|{y}";

    static void Main()
    {
        Console.WriteLine(E32(1, new S32 { A = 31, B = 32, C = 33, D = 34 }, 2));
    }
}

E32 must be ReadyToRun-compiled. Interpreted execution is correct.

Expected

1|31,32,33,34|2

Actual

1|32,33,34,2|0

s.A reads the input B, s.B reads C, s.C reads D, s.D reads the trailing int y (2), and y reads garbage (0) — i.e. the struct argument is read one 8-byte word too high.

Notes

• 16-byte ({ long, long }) and 24-byte ({ long, long, long }) structs pass correctly; only the 32-byte (four-word) struct is affected.
• Reproduces with a direct call; reflection-invoking the same method corrupts it further.

Configuration

• -os browser -a wasm, CoreCLR, PublishReadyToRun (crossgen2, --obj-format:wasm)
• Reproduces in Node and in the browser.

Note

This issue was written with the assistance of GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

cc @lewing @AndyAyersMS

[AndyAyersMS]

AI's take on this:

Wasm thunks are keyed globally by signature string, and structs are encoded as S<N>  — size only, no alignment.  WasmLowering.RaiseSignature  recovers the parameter type via  GetCachedStructOfSize(N) , which returns whatever struct of that size the compilation happened to see first.

But the wasm ArgIterator aligns a struct's transition-block slot to  clamp(structAlignment, 8, 16) . So a 32-byte struct of  long s (align 8) and one of  Int128 s (align 16) have different argument layouts yet share one thunk.

CoreLib's cached size-32 stand-in is  ValueTuple<Int128,Int128>  → align 16. Its  viS32ip  thunk therefore places the struct at TB+24 /  y  at TB+56, while the real (align-8) layout is TB+16 / TB+48. Every arg after the first shifts by 8 — exactly the reported corruption.

Explains everything: only size 32; only when a preceding arg leaves the offset at 8 (not 16-aligned); only the first call (later calls go direct-R2R, bypassing the interp→R2R thunk); and why  (long,S32,int) / (int,int,S32,int)  pass (no CoreLib thunk for those strings, so the app's own correct thunk is used).

[AndyAyersMS]

I can put up a plausible fix, but wonder if this intersects with #131492. Let me dig in a bit more.