[wasm] test case for broken .locals init

[pavelsavara]

See #71425

[ghost]

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

Issue Details

---

New unit test System.Runtime.InteropServices.JavaScript.Tests.JavaScriptTests
showing that it takes 1000 calls to JS to expose un-initialised out int something argument on icall.
Only when in Release and with [MethodImpl(MethodImplOptions.AggressiveInlining)]

Author:	pavelsavara
Assignees:	pavelsavara
Labels:	arch-wasm, area-System.Runtime.InteropServices.JavaScript
Milestone:	-

[pavelsavara]

cc @vargaz

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[vargaz]

Seems to be caused by the tiering code.
@BrzVlad

[BrzVlad]

This just looks like #37955. Is this showing somewhere relevant ?

[vargaz]

The failure seems to happen when tiering up.

[BrzVlad]

The failure seems to happen when tiering up.

Because this issue was always present with optimized code (with inlining). It's not related to tiering.

[pavelsavara]

This just looks like #37955. Is this showing somewhere relevant ?

I can avoid it in the interop code which lead me to discovery of this.
But BCL full AggressiveInlining, that would break there too, right ?

[BrzVlad]

@pavelsavara This issue doesn't happen normally because C# requires you to initialize all vars explicitly.

[pavelsavara]

But BCL is also full of PInvoke. Are there reasons why this is not worth fixing ?

[BrzVlad]

I'm not sure I understand why this is a problem. The pinvoke signature has the argument defined as out. So this logically means that this argument passes no value and the native code is responsible to initialize it to whatever the result of the pinvoke is. Why would the native code rely on this variable to be already initialized to 0, given that it has to write the result to it ? If the pinvoke does expect a certain value, then you should pass ref and C# would force you to initialize the variable.