[wasm] Delete hand-written R2R-to-interpreter thunks; use crossgen2's

[pavelsavara]

Addresses @jkotas's feedback on #132926: rather than grow another static table of hand-written R2R-to-interpreter thunks, delete them and rely on the ones crossgen2 already emits.

What

The R2R-to-interpreter transition thunks were a hand-written table in vm/wasm/helpers.cpp (g_wasmPortableEntryPointThunks + the CallInterpreter_* functions). crossgen2 already emits these thunks into each R2R image (WasmR2RToInterpreterThunkNode, keyed "I"+signature, from #127483), and the runtime discovers them by string via LookupPregeneratedThunkByString. The static table was therefore a buggy, incomplete duplicate that shadowed the correct crossgen2 thunks — it was checked first, yet had no float/double-return shape, among others.

This removes the table and routes LookupPortableEntryPointThunk solely through the R2R string hash. Pure interpreter keeps working via the existing deferral path (EnsurePortableEntryPointIsCallableFromR2R → AddPendingPortableEntryPointThunk, resolved when an R2R module loads). helpers.cpp: −368 / +5.

Test

Adds src/tests/readytorun/wasm/WasmInterpreterTransitions, exercising both transition directions across struct (S8/S12/S16), scalar, void, and float/double returns. [BypassReadyToRun] + composite R2R ensures every cross-call actually hits a thunk (a wrong parameter order still type-checks under call_indirect, so the cases assert pinned values).

Validation (local, Windows host)

• Browser CoreCLR: WasmInterpreterTransitions passes (Expected 100 / Actual 100).
• Sibling browser R2R tests pass: WasmR2RStructAlignment, Runtime_131640.
• WasmArgumentLayoutTests (crossgen2 lowering, unchanged here): 52 / 52.
• console-node CoreCLR sample runs clean.
• helpers.cpp compiles for both browser and wasi (the wasi target runtime builds).

Commits

1. [wasm] Treat wasi as a cross-target in the Windows build scripts — a separable wasi-on-Windows build fix (also carried in [wasm] Generate the native-entry-point-to-interpreter thunk table #132926) so the wasi CoreCLR build configures on a Windows host. This is only one of the two separable wasi build fixes; the configureplatform.cmake cross-components fix is not included, so a full wasi build is not green from this PR alone. Can be split into its own PR if preferred.
2. [wasm] Delete hand-written R2R-to-interpreter thunks; use crossgen2's.

Draft while gathering CI signal.

Note

This PR description was generated with AI assistance.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[pavelsavara]

Why the pregenerated portable-entry-point thunk table cannot be deleted

The R2R→interpreter thunk is needed whenever a caller reaches an interpreted method through a materialized native entry point — i.e. any call_indirect: ldftn/delegate/virtual dispatch, plus every R2R→interpreter call. On wasm that entry point is an index into __indirect_function_table, and the thunk is the function that builds the interpreter frame and enters it with the right signature.

crossgen2 emits these thunks (WasmR2RToInterpreterThunkNode, keyed 'I'+sig) into each R2R image, discovered at runtime via LookupPregeneratedThunkByString. That source exists only for shapes a loaded, crossgen'd module rooted.

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

But the interpreter still needs a portable entry point the instant managed code takes a delegate/function-pointer to an interpreted method.

This leaves us with

• pre-generated C thunks for known signatures.
• crossgen'd thunks
  • R2R webcil which even pure interp would load module to be able to install those thunks
  • LLVM linkable .o file that dotnet.native.wasm would link

Both options are incomplete because we don't pre-create thunks for signatures in the app assemblies.
Doing so means running crossgen in the dev-loop too.

None of this is on critical path for me, to unblock Blazor on R2R. I'm closing this and we will re-consider later.

I'm back to #132926

cc @jkotas@davidwrighton

[jkotas]

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

Right. It means that you should not need any R2R->interpreter thunks (there is no R2R code), managed->managed calls should be going through interpreter without any intermediate thunks, and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

I'm back to #132926

The change in #132926 is dead-end.

[pavelsavara]

It means that you should not need any R2R->interpreter thunks (there is no R2R code)

Correct no R2R code.

and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

That's what #132926 is generating.
I think the subject of that PR is confusion, it should speak about "interp-to-native-entrypoint" thunks rather than "interp-to-R2R" thunks. I will update that PR.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable — from the interpreter and from native/host code — which requires a real, per-signature wasm function (the thunk) that marshals the typed args and re-enters the interpreter.

• Default constructors — callhelpers.cpp:581: RuntimeHelpers.CallDefaultConstructor does a calli ctorCode. In pure interp that helper runs interpreted, and its calli calls through _pActualCode = the thunk.
• Finalizers — comutilnative.cpp:797: RunFinalizers invokes the finalizer via its function pointer.
• Class constructors — methodtable.cpp:3580: CallClassConstructor invokes the cctor via its function pointer.
• Plus the original CI failure: Dictionary.Add materializing an interpreted comparer's entry point.

[jkotas]

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable

That's not correct. Pure interpreter is expected to use portable-entry-point for managed method delegate. This portable-entry-point does not have to have _pActualCode filled in when the thunk does not exist.

runtime/src/coreclr/vm/interpexec.cpp

Lines 3355 to 3356 in 04a9b1a

	if (PortableEntryPoint::PrefersInterpreterEntryPoint(calliFunctionPointer) || !PortableEntryPoint::HasNativeEntryPoint(calliFunctionPointer))
	gotoCALL_INTERP_METHOD;

is expected to detect this situation and keep interpreting the call without ever calling via _pActualCode.

[jkotas]

Do you see the condition that I have linked to be false in the problematic cases? There are multiple clones of this condition in interpexec.cpp handling different types of calls.

[pavelsavara]

Addresses @jkotas's feedback on #132926: rather than grow another static table of hand-written R2R-to-interpreter thunks, delete them and rely on the ones crossgen2 already emits.

What

The R2R-to-interpreter transition thunks were a hand-written table in vm/wasm/helpers.cpp (g_wasmPortableEntryPointThunks + the CallInterpreter_* functions). crossgen2 already emits these thunks into each R2R image (WasmR2RToInterpreterThunkNode, keyed "I"+signature, from #127483), and the runtime discovers them by string via LookupPregeneratedThunkByString. The static table was therefore a buggy, incomplete duplicate that shadowed the correct crossgen2 thunks — it was checked first, yet had no float/double-return shape, among others.

This removes the table and routes LookupPortableEntryPointThunk solely through the R2R string hash. Pure interpreter keeps working via the existing deferral path (EnsurePortableEntryPointIsCallableFromR2R → AddPendingPortableEntryPointThunk, resolved when an R2R module loads). helpers.cpp: −368 / +5.

Test

Adds src/tests/readytorun/wasm/WasmInterpreterTransitions, exercising both transition directions across struct (S8/S12/S16), scalar, void, and float/double returns. [BypassReadyToRun] + composite R2R ensures every cross-call actually hits a thunk (a wrong parameter order still type-checks under call_indirect, so the cases assert pinned values).

Validation (local, Windows host)

• Browser CoreCLR: WasmInterpreterTransitions passes (Expected 100 / Actual 100).
• Sibling browser R2R tests pass: WasmR2RStructAlignment, Runtime_131640.
• WasmArgumentLayoutTests (crossgen2 lowering, unchanged here): 52 / 52.
• console-node CoreCLR sample runs clean.
• helpers.cpp compiles for both browser and wasi (the wasi target runtime builds).

Commits

1. [wasm] Treat wasi as a cross-target in the Windows build scripts — a separable wasi-on-Windows build fix (also carried in [wasm] Generate the native-entry-point-to-interpreter thunk table #132926) so the wasi CoreCLR build configures on a Windows host. This is only one of the two separable wasi build fixes; the configureplatform.cmake cross-components fix is not included, so a full wasi build is not green from this PR alone. Can be split into its own PR if preferred.
2. [wasm] Delete hand-written R2R-to-interpreter thunks; use crossgen2's.

Draft while gathering CI signal.

Note

This PR description was generated with AI assistance.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[pavelsavara]

Why the pregenerated portable-entry-point thunk table cannot be deleted

The R2R→interpreter thunk is needed whenever a caller reaches an interpreted method through a materialized native entry point — i.e. any call_indirect: ldftn/delegate/virtual dispatch, plus every R2R→interpreter call. On wasm that entry point is an index into __indirect_function_table, and the thunk is the function that builds the interpreter frame and enters it with the right signature.

crossgen2 emits these thunks (WasmR2RToInterpreterThunkNode, keyed 'I'+sig) into each R2R image, discovered at runtime via LookupPregeneratedThunkByString. That source exists only for shapes a loaded, crossgen'd module rooted.

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

But the interpreter still needs a portable entry point the instant managed code takes a delegate/function-pointer to an interpreted method.

This leaves us with

• pre-generated C thunks for known signatures.
• crossgen'd thunks
  • R2R webcil which even pure interp would load module to be able to install those thunks
  • LLVM linkable .o file that dotnet.native.wasm would link

Both options are incomplete because we don't pre-create thunks for signatures in the app assemblies.
Doing so means running crossgen in the dev-loop too.

None of this is on critical path for me, to unblock Blazor on R2R. I'm closing this and we will re-consider later.

I'm back to #132926

cc @jkotas@davidwrighton

[jkotas]

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

Right. It means that you should not need any R2R->interpreter thunks (there is no R2R code), managed->managed calls should be going through interpreter without any intermediate thunks, and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

I'm back to #132926

The change in #132926 is dead-end.

[pavelsavara]

It means that you should not need any R2R->interpreter thunks (there is no R2R code)

Correct no R2R code.

and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

That's what #132926 is generating.
I think the subject of that PR is confusion, it should speak about "interp-to-native-entrypoint" thunks rather than "interp-to-R2R" thunks. I will update that PR.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable — from the interpreter and from native/host code — which requires a real, per-signature wasm function (the thunk) that marshals the typed args and re-enters the interpreter.

• Default constructors — callhelpers.cpp:581: RuntimeHelpers.CallDefaultConstructor does a calli ctorCode. In pure interp that helper runs interpreted, and its calli calls through _pActualCode = the thunk.
• Finalizers — comutilnative.cpp:797: RunFinalizers invokes the finalizer via its function pointer.
• Class constructors — methodtable.cpp:3580: CallClassConstructor invokes the cctor via its function pointer.
• Plus the original CI failure: Dictionary.Add materializing an interpreted comparer's entry point.

[jkotas]

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable

That's not correct. Pure interpreter is expected to use portable-entry-point for managed method delegate. This portable-entry-point does not have to have _pActualCode filled in when the thunk does not exist.

runtime/src/coreclr/vm/interpexec.cpp

Lines 3355 to 3356 in 04a9b1a

	if (PortableEntryPoint::PrefersInterpreterEntryPoint(calliFunctionPointer) || !PortableEntryPoint::HasNativeEntryPoint(calliFunctionPointer))
	gotoCALL_INTERP_METHOD;

is expected to detect this situation and keep interpreting the call without ever calling via _pActualCode.

[jkotas]

Do you see the condition that I have linked to be false in the problematic cases? There are multiple clones of this condition in interpexec.cpp handling different types of calls.

[pavelsavara]

Addresses @jkotas's feedback on #132926: rather than grow another static table of hand-written R2R-to-interpreter thunks, delete them and rely on the ones crossgen2 already emits.

What

The R2R-to-interpreter transition thunks were a hand-written table in vm/wasm/helpers.cpp (g_wasmPortableEntryPointThunks + the CallInterpreter_* functions). crossgen2 already emits these thunks into each R2R image (WasmR2RToInterpreterThunkNode, keyed "I"+signature, from #127483), and the runtime discovers them by string via LookupPregeneratedThunkByString. The static table was therefore a buggy, incomplete duplicate that shadowed the correct crossgen2 thunks — it was checked first, yet had no float/double-return shape, among others.

This removes the table and routes LookupPortableEntryPointThunk solely through the R2R string hash. Pure interpreter keeps working via the existing deferral path (EnsurePortableEntryPointIsCallableFromR2R → AddPendingPortableEntryPointThunk, resolved when an R2R module loads). helpers.cpp: −368 / +5.

Test

Adds src/tests/readytorun/wasm/WasmInterpreterTransitions, exercising both transition directions across struct (S8/S12/S16), scalar, void, and float/double returns. [BypassReadyToRun] + composite R2R ensures every cross-call actually hits a thunk (a wrong parameter order still type-checks under call_indirect, so the cases assert pinned values).

Validation (local, Windows host)

• Browser CoreCLR: WasmInterpreterTransitions passes (Expected 100 / Actual 100).
• Sibling browser R2R tests pass: WasmR2RStructAlignment, Runtime_131640.
• WasmArgumentLayoutTests (crossgen2 lowering, unchanged here): 52 / 52.
• console-node CoreCLR sample runs clean.
• helpers.cpp compiles for both browser and wasi (the wasi target runtime builds).

Commits

1. [wasm] Treat wasi as a cross-target in the Windows build scripts — a separable wasi-on-Windows build fix (also carried in [wasm] Generate the native-entry-point-to-interpreter thunk table #132926) so the wasi CoreCLR build configures on a Windows host. This is only one of the two separable wasi build fixes; the configureplatform.cmake cross-components fix is not included, so a full wasi build is not green from this PR alone. Can be split into its own PR if preferred.
2. [wasm] Delete hand-written R2R-to-interpreter thunks; use crossgen2's.

Draft while gathering CI signal.

Note

This PR description was generated with AI assistance.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[pavelsavara]

Why the pregenerated portable-entry-point thunk table cannot be deleted

The R2R→interpreter thunk is needed whenever a caller reaches an interpreted method through a materialized native entry point — i.e. any call_indirect: ldftn/delegate/virtual dispatch, plus every R2R→interpreter call. On wasm that entry point is an index into __indirect_function_table, and the thunk is the function that builds the interpreter frame and enters it with the right signature.

crossgen2 emits these thunks (WasmR2RToInterpreterThunkNode, keyed 'I'+sig) into each R2R image, discovered at runtime via LookupPregeneratedThunkByString. That source exists only for shapes a loaded, crossgen'd module rooted.

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

But the interpreter still needs a portable entry point the instant managed code takes a delegate/function-pointer to an interpreted method.

This leaves us with

• pre-generated C thunks for known signatures.
• crossgen'd thunks
  • R2R webcil which even pure interp would load module to be able to install those thunks
  • LLVM linkable .o file that dotnet.native.wasm would link

Both options are incomplete because we don't pre-create thunks for signatures in the app assemblies.
Doing so means running crossgen in the dev-loop too.

None of this is on critical path for me, to unblock Blazor on R2R. I'm closing this and we will re-consider later.

I'm back to #132926

cc @jkotas@davidwrighton

[jkotas]

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

Right. It means that you should not need any R2R->interpreter thunks (there is no R2R code), managed->managed calls should be going through interpreter without any intermediate thunks, and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

I'm back to #132926

The change in #132926 is dead-end.

[pavelsavara]

It means that you should not need any R2R->interpreter thunks (there is no R2R code)

Correct no R2R code.

and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

That's what #132926 is generating.
I think the subject of that PR is confusion, it should speak about "interp-to-native-entrypoint" thunks rather than "interp-to-R2R" thunks. I will update that PR.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable — from the interpreter and from native/host code — which requires a real, per-signature wasm function (the thunk) that marshals the typed args and re-enters the interpreter.

• Default constructors — callhelpers.cpp:581: RuntimeHelpers.CallDefaultConstructor does a calli ctorCode. In pure interp that helper runs interpreted, and its calli calls through _pActualCode = the thunk.
• Finalizers — comutilnative.cpp:797: RunFinalizers invokes the finalizer via its function pointer.
• Class constructors — methodtable.cpp:3580: CallClassConstructor invokes the cctor via its function pointer.
• Plus the original CI failure: Dictionary.Add materializing an interpreted comparer's entry point.

[jkotas]

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable

That's not correct. Pure interpreter is expected to use portable-entry-point for managed method delegate. This portable-entry-point does not have to have _pActualCode filled in when the thunk does not exist.

runtime/src/coreclr/vm/interpexec.cpp

Lines 3355 to 3356 in 04a9b1a

	if (PortableEntryPoint::PrefersInterpreterEntryPoint(calliFunctionPointer) || !PortableEntryPoint::HasNativeEntryPoint(calliFunctionPointer))
	gotoCALL_INTERP_METHOD;

is expected to detect this situation and keep interpreting the call without ever calling via _pActualCode.

[jkotas]

Do you see the condition that I have linked to be false in the problematic cases? There are multiple clones of this condition in interpexec.cpp handling different types of calls.

[pavelsavara]

Addresses @jkotas's feedback on #132926: rather than grow another static table of hand-written R2R-to-interpreter thunks, delete them and rely on the ones crossgen2 already emits.

What

The R2R-to-interpreter transition thunks were a hand-written table in vm/wasm/helpers.cpp (g_wasmPortableEntryPointThunks + the CallInterpreter_* functions). crossgen2 already emits these thunks into each R2R image (WasmR2RToInterpreterThunkNode, keyed "I"+signature, from #127483), and the runtime discovers them by string via LookupPregeneratedThunkByString. The static table was therefore a buggy, incomplete duplicate that shadowed the correct crossgen2 thunks — it was checked first, yet had no float/double-return shape, among others.

This removes the table and routes LookupPortableEntryPointThunk solely through the R2R string hash. Pure interpreter keeps working via the existing deferral path (EnsurePortableEntryPointIsCallableFromR2R → AddPendingPortableEntryPointThunk, resolved when an R2R module loads). helpers.cpp: −368 / +5.

Test

Adds src/tests/readytorun/wasm/WasmInterpreterTransitions, exercising both transition directions across struct (S8/S12/S16), scalar, void, and float/double returns. [BypassReadyToRun] + composite R2R ensures every cross-call actually hits a thunk (a wrong parameter order still type-checks under call_indirect, so the cases assert pinned values).

Validation (local, Windows host)

• Browser CoreCLR: WasmInterpreterTransitions passes (Expected 100 / Actual 100).
• Sibling browser R2R tests pass: WasmR2RStructAlignment, Runtime_131640.
• WasmArgumentLayoutTests (crossgen2 lowering, unchanged here): 52 / 52.
• console-node CoreCLR sample runs clean.
• helpers.cpp compiles for both browser and wasi (the wasi target runtime builds).

Commits

1. [wasm] Treat wasi as a cross-target in the Windows build scripts — a separable wasi-on-Windows build fix (also carried in [wasm] Generate the native-entry-point-to-interpreter thunk table #132926) so the wasi CoreCLR build configures on a Windows host. This is only one of the two separable wasi build fixes; the configureplatform.cmake cross-components fix is not included, so a full wasi build is not green from this PR alone. Can be split into its own PR if preferred.
2. [wasm] Delete hand-written R2R-to-interpreter thunks; use crossgen2's.

Draft while gathering CI signal.

Note

This PR description was generated with AI assistance.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[pavelsavara]

Why the pregenerated portable-entry-point thunk table cannot be deleted

The R2R→interpreter thunk is needed whenever a caller reaches an interpreted method through a materialized native entry point — i.e. any call_indirect: ldftn/delegate/virtual dispatch, plus every R2R→interpreter call. On wasm that entry point is an index into __indirect_function_table, and the thunk is the function that builds the interpreter frame and enters it with the right signature.

crossgen2 emits these thunks (WasmR2RToInterpreterThunkNode, keyed 'I'+sig) into each R2R image, discovered at runtime via LookupPregeneratedThunkByString. That source exists only for shapes a loaded, crossgen'd module rooted.

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

But the interpreter still needs a portable entry point the instant managed code takes a delegate/function-pointer to an interpreted method.

This leaves us with

• pre-generated C thunks for known signatures.
• crossgen'd thunks
  • R2R webcil which even pure interp would load module to be able to install those thunks
  • LLVM linkable .o file that dotnet.native.wasm would link

Both options are incomplete because we don't pre-create thunks for signatures in the app assemblies.
Doing so means running crossgen in the dev-loop too.

None of this is on critical path for me, to unblock Blazor on R2R. I'm closing this and we will re-consider later.

I'm back to #132926

cc @jkotas@davidwrighton

[jkotas]

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

Right. It means that you should not need any R2R->interpreter thunks (there is no R2R code), managed->managed calls should be going through interpreter without any intermediate thunks, and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

I'm back to #132926

The change in #132926 is dead-end.

[pavelsavara]

It means that you should not need any R2R->interpreter thunks (there is no R2R code)

Correct no R2R code.

and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

That's what #132926 is generating.
I think the subject of that PR is confusion, it should speak about "interp-to-native-entrypoint" thunks rather than "interp-to-R2R" thunks. I will update that PR.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable — from the interpreter and from native/host code — which requires a real, per-signature wasm function (the thunk) that marshals the typed args and re-enters the interpreter.

• Default constructors — callhelpers.cpp:581: RuntimeHelpers.CallDefaultConstructor does a calli ctorCode. In pure interp that helper runs interpreted, and its calli calls through _pActualCode = the thunk.
• Finalizers — comutilnative.cpp:797: RunFinalizers invokes the finalizer via its function pointer.
• Class constructors — methodtable.cpp:3580: CallClassConstructor invokes the cctor via its function pointer.
• Plus the original CI failure: Dictionary.Add materializing an interpreted comparer's entry point.

[jkotas]

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable

That's not correct. Pure interpreter is expected to use portable-entry-point for managed method delegate. This portable-entry-point does not have to have _pActualCode filled in when the thunk does not exist.

runtime/src/coreclr/vm/interpexec.cpp

Lines 3355 to 3356 in 04a9b1a

	if (PortableEntryPoint::PrefersInterpreterEntryPoint(calliFunctionPointer) || !PortableEntryPoint::HasNativeEntryPoint(calliFunctionPointer))
	gotoCALL_INTERP_METHOD;

is expected to detect this situation and keep interpreting the call without ever calling via _pActualCode.

[jkotas]

Do you see the condition that I have linked to be false in the problematic cases? There are multiple clones of this condition in interpexec.cpp handling different types of calls.

[pavelsavara]

Addresses @jkotas's feedback on #132926: rather than grow another static table of hand-written R2R-to-interpreter thunks, delete them and rely on the ones crossgen2 already emits.

What

The R2R-to-interpreter transition thunks were a hand-written table in vm/wasm/helpers.cpp (g_wasmPortableEntryPointThunks + the CallInterpreter_* functions). crossgen2 already emits these thunks into each R2R image (WasmR2RToInterpreterThunkNode, keyed "I"+signature, from #127483), and the runtime discovers them by string via LookupPregeneratedThunkByString. The static table was therefore a buggy, incomplete duplicate that shadowed the correct crossgen2 thunks — it was checked first, yet had no float/double-return shape, among others.

This removes the table and routes LookupPortableEntryPointThunk solely through the R2R string hash. Pure interpreter keeps working via the existing deferral path (EnsurePortableEntryPointIsCallableFromR2R → AddPendingPortableEntryPointThunk, resolved when an R2R module loads). helpers.cpp: −368 / +5.

Test

Adds src/tests/readytorun/wasm/WasmInterpreterTransitions, exercising both transition directions across struct (S8/S12/S16), scalar, void, and float/double returns. [BypassReadyToRun] + composite R2R ensures every cross-call actually hits a thunk (a wrong parameter order still type-checks under call_indirect, so the cases assert pinned values).

Validation (local, Windows host)

• Browser CoreCLR: WasmInterpreterTransitions passes (Expected 100 / Actual 100).
• Sibling browser R2R tests pass: WasmR2RStructAlignment, Runtime_131640.
• WasmArgumentLayoutTests (crossgen2 lowering, unchanged here): 52 / 52.
• console-node CoreCLR sample runs clean.
• helpers.cpp compiles for both browser and wasi (the wasi target runtime builds).

Commits

1. [wasm] Treat wasi as a cross-target in the Windows build scripts — a separable wasi-on-Windows build fix (also carried in [wasm] Generate the native-entry-point-to-interpreter thunk table #132926) so the wasi CoreCLR build configures on a Windows host. This is only one of the two separable wasi build fixes; the configureplatform.cmake cross-components fix is not included, so a full wasi build is not green from this PR alone. Can be split into its own PR if preferred.
2. [wasm] Delete hand-written R2R-to-interpreter thunks; use crossgen2's.

Draft while gathering CI signal.

Note

This PR description was generated with AI assistance.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[pavelsavara]

Why the pregenerated portable-entry-point thunk table cannot be deleted

The R2R→interpreter thunk is needed whenever a caller reaches an interpreted method through a materialized native entry point — i.e. any call_indirect: ldftn/delegate/virtual dispatch, plus every R2R→interpreter call. On wasm that entry point is an index into __indirect_function_table, and the thunk is the function that builds the interpreter frame and enters it with the right signature.

crossgen2 emits these thunks (WasmR2RToInterpreterThunkNode, keyed 'I'+sig) into each R2R image, discovered at runtime via LookupPregeneratedThunkByString. That source exists only for shapes a loaded, crossgen'd module rooted.

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

But the interpreter still needs a portable entry point the instant managed code takes a delegate/function-pointer to an interpreted method.

This leaves us with

• pre-generated C thunks for known signatures.
• crossgen'd thunks
  • R2R webcil which even pure interp would load module to be able to install those thunks
  • LLVM linkable .o file that dotnet.native.wasm would link

Both options are incomplete because we don't pre-create thunks for signatures in the app assemblies.
Doing so means running crossgen in the dev-loop too.

None of this is on critical path for me, to unblock Blazor on R2R. I'm closing this and we will re-consider later.

I'm back to #132926

cc @jkotas@davidwrighton

[jkotas]

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

Right. It means that you should not need any R2R->interpreter thunks (there is no R2R code), managed->managed calls should be going through interpreter without any intermediate thunks, and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

I'm back to #132926

The change in #132926 is dead-end.

[pavelsavara]

It means that you should not need any R2R->interpreter thunks (there is no R2R code)

Correct no R2R code.

and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

That's what #132926 is generating.
I think the subject of that PR is confusion, it should speak about "interp-to-native-entrypoint" thunks rather than "interp-to-R2R" thunks. I will update that PR.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable — from the interpreter and from native/host code — which requires a real, per-signature wasm function (the thunk) that marshals the typed args and re-enters the interpreter.

• Default constructors — callhelpers.cpp:581: RuntimeHelpers.CallDefaultConstructor does a calli ctorCode. In pure interp that helper runs interpreted, and its calli calls through _pActualCode = the thunk.
• Finalizers — comutilnative.cpp:797: RunFinalizers invokes the finalizer via its function pointer.
• Class constructors — methodtable.cpp:3580: CallClassConstructor invokes the cctor via its function pointer.
• Plus the original CI failure: Dictionary.Add materializing an interpreted comparer's entry point.

[jkotas]

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable

That's not correct. Pure interpreter is expected to use portable-entry-point for managed method delegate. This portable-entry-point does not have to have _pActualCode filled in when the thunk does not exist.

runtime/src/coreclr/vm/interpexec.cpp

Lines 3355 to 3356 in 04a9b1a

	if (PortableEntryPoint::PrefersInterpreterEntryPoint(calliFunctionPointer) || !PortableEntryPoint::HasNativeEntryPoint(calliFunctionPointer))
	gotoCALL_INTERP_METHOD;

is expected to detect this situation and keep interpreting the call without ever calling via _pActualCode.

[jkotas]

Do you see the condition that I have linked to be false in the problematic cases? There are multiple clones of this condition in interpexec.cpp handling different types of calls.

[pavelsavara]

Addresses @jkotas's feedback on #132926: rather than grow another static table of hand-written R2R-to-interpreter thunks, delete them and rely on the ones crossgen2 already emits.

What

The R2R-to-interpreter transition thunks were a hand-written table in vm/wasm/helpers.cpp (g_wasmPortableEntryPointThunks + the CallInterpreter_* functions). crossgen2 already emits these thunks into each R2R image (WasmR2RToInterpreterThunkNode, keyed "I"+signature, from #127483), and the runtime discovers them by string via LookupPregeneratedThunkByString. The static table was therefore a buggy, incomplete duplicate that shadowed the correct crossgen2 thunks — it was checked first, yet had no float/double-return shape, among others.

This removes the table and routes LookupPortableEntryPointThunk solely through the R2R string hash. Pure interpreter keeps working via the existing deferral path (EnsurePortableEntryPointIsCallableFromR2R → AddPendingPortableEntryPointThunk, resolved when an R2R module loads). helpers.cpp: −368 / +5.

Test

Adds src/tests/readytorun/wasm/WasmInterpreterTransitions, exercising both transition directions across struct (S8/S12/S16), scalar, void, and float/double returns. [BypassReadyToRun] + composite R2R ensures every cross-call actually hits a thunk (a wrong parameter order still type-checks under call_indirect, so the cases assert pinned values).

Validation (local, Windows host)

• Browser CoreCLR: WasmInterpreterTransitions passes (Expected 100 / Actual 100).
• Sibling browser R2R tests pass: WasmR2RStructAlignment, Runtime_131640.
• WasmArgumentLayoutTests (crossgen2 lowering, unchanged here): 52 / 52.
• console-node CoreCLR sample runs clean.
• helpers.cpp compiles for both browser and wasi (the wasi target runtime builds).

Commits

1. [wasm] Treat wasi as a cross-target in the Windows build scripts — a separable wasi-on-Windows build fix (also carried in [wasm] Generate the native-entry-point-to-interpreter thunk table #132926) so the wasi CoreCLR build configures on a Windows host. This is only one of the two separable wasi build fixes; the configureplatform.cmake cross-components fix is not included, so a full wasi build is not green from this PR alone. Can be split into its own PR if preferred.
2. [wasm] Delete hand-written R2R-to-interpreter thunks; use crossgen2's.

Draft while gathering CI signal.

Note

This PR description was generated with AI assistance.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[pavelsavara]

Why the pregenerated portable-entry-point thunk table cannot be deleted

The R2R→interpreter thunk is needed whenever a caller reaches an interpreted method through a materialized native entry point — i.e. any call_indirect: ldftn/delegate/virtual dispatch, plus every R2R→interpreter call. On wasm that entry point is an index into __indirect_function_table, and the thunk is the function that builds the interpreter frame and enters it with the right signature.

crossgen2 emits these thunks (WasmR2RToInterpreterThunkNode, keyed 'I'+sig) into each R2R image, discovered at runtime via LookupPregeneratedThunkByString. That source exists only for shapes a loaded, crossgen'd module rooted.

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

But the interpreter still needs a portable entry point the instant managed code takes a delegate/function-pointer to an interpreted method.

This leaves us with

• pre-generated C thunks for known signatures.
• crossgen'd thunks
  • R2R webcil which even pure interp would load module to be able to install those thunks
  • LLVM linkable .o file that dotnet.native.wasm would link

Both options are incomplete because we don't pre-create thunks for signatures in the app assemblies.
Doing so means running crossgen in the dev-loop too.

None of this is on critical path for me, to unblock Blazor on R2R. I'm closing this and we will re-consider later.

I'm back to #132926

cc @jkotas@davidwrighton

[jkotas]

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

Right. It means that you should not need any R2R->interpreter thunks (there is no R2R code), managed->managed calls should be going through interpreter without any intermediate thunks, and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

I'm back to #132926

The change in #132926 is dead-end.

[pavelsavara]

It means that you should not need any R2R->interpreter thunks (there is no R2R code)

Correct no R2R code.

and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

That's what #132926 is generating.
I think the subject of that PR is confusion, it should speak about "interp-to-native-entrypoint" thunks rather than "interp-to-R2R" thunks. I will update that PR.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable — from the interpreter and from native/host code — which requires a real, per-signature wasm function (the thunk) that marshals the typed args and re-enters the interpreter.

• Default constructors — callhelpers.cpp:581: RuntimeHelpers.CallDefaultConstructor does a calli ctorCode. In pure interp that helper runs interpreted, and its calli calls through _pActualCode = the thunk.
• Finalizers — comutilnative.cpp:797: RunFinalizers invokes the finalizer via its function pointer.
• Class constructors — methodtable.cpp:3580: CallClassConstructor invokes the cctor via its function pointer.
• Plus the original CI failure: Dictionary.Add materializing an interpreted comparer's entry point.

[jkotas]

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable

That's not correct. Pure interpreter is expected to use portable-entry-point for managed method delegate. This portable-entry-point does not have to have _pActualCode filled in when the thunk does not exist.

runtime/src/coreclr/vm/interpexec.cpp

Lines 3355 to 3356 in 04a9b1a

	if (PortableEntryPoint::PrefersInterpreterEntryPoint(calliFunctionPointer) || !PortableEntryPoint::HasNativeEntryPoint(calliFunctionPointer))
	gotoCALL_INTERP_METHOD;

is expected to detect this situation and keep interpreting the call without ever calling via _pActualCode.

[jkotas]

Do you see the condition that I have linked to be false in the problematic cases? There are multiple clones of this condition in interpexec.cpp handling different types of calls.

[pavelsavara]

Addresses @jkotas's feedback on #132926: rather than grow another static table of hand-written R2R-to-interpreter thunks, delete them and rely on the ones crossgen2 already emits.

What

The R2R-to-interpreter transition thunks were a hand-written table in vm/wasm/helpers.cpp (g_wasmPortableEntryPointThunks + the CallInterpreter_* functions). crossgen2 already emits these thunks into each R2R image (WasmR2RToInterpreterThunkNode, keyed "I"+signature, from #127483), and the runtime discovers them by string via LookupPregeneratedThunkByString. The static table was therefore a buggy, incomplete duplicate that shadowed the correct crossgen2 thunks — it was checked first, yet had no float/double-return shape, among others.

This removes the table and routes LookupPortableEntryPointThunk solely through the R2R string hash. Pure interpreter keeps working via the existing deferral path (EnsurePortableEntryPointIsCallableFromR2R → AddPendingPortableEntryPointThunk, resolved when an R2R module loads). helpers.cpp: −368 / +5.

Test

Adds src/tests/readytorun/wasm/WasmInterpreterTransitions, exercising both transition directions across struct (S8/S12/S16), scalar, void, and float/double returns. [BypassReadyToRun] + composite R2R ensures every cross-call actually hits a thunk (a wrong parameter order still type-checks under call_indirect, so the cases assert pinned values).

Validation (local, Windows host)

• Browser CoreCLR: WasmInterpreterTransitions passes (Expected 100 / Actual 100).
• Sibling browser R2R tests pass: WasmR2RStructAlignment, Runtime_131640.
• WasmArgumentLayoutTests (crossgen2 lowering, unchanged here): 52 / 52.
• console-node CoreCLR sample runs clean.
• helpers.cpp compiles for both browser and wasi (the wasi target runtime builds).

Commits

1. [wasm] Treat wasi as a cross-target in the Windows build scripts — a separable wasi-on-Windows build fix (also carried in [wasm] Generate the native-entry-point-to-interpreter thunk table #132926) so the wasi CoreCLR build configures on a Windows host. This is only one of the two separable wasi build fixes; the configureplatform.cmake cross-components fix is not included, so a full wasi build is not green from this PR alone. Can be split into its own PR if preferred.
2. [wasm] Delete hand-written R2R-to-interpreter thunks; use crossgen2's.

Draft while gathering CI signal.

Note

This PR description was generated with AI assistance.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[pavelsavara]

Why the pregenerated portable-entry-point thunk table cannot be deleted

The R2R→interpreter thunk is needed whenever a caller reaches an interpreted method through a materialized native entry point — i.e. any call_indirect: ldftn/delegate/virtual dispatch, plus every R2R→interpreter call. On wasm that entry point is an index into __indirect_function_table, and the thunk is the function that builds the interpreter frame and enters it with the right signature.

crossgen2 emits these thunks (WasmR2RToInterpreterThunkNode, keyed 'I'+sig) into each R2R image, discovered at runtime via LookupPregeneratedThunkByString. That source exists only for shapes a loaded, crossgen'd module rooted.

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

But the interpreter still needs a portable entry point the instant managed code takes a delegate/function-pointer to an interpreted method.

This leaves us with

• pre-generated C thunks for known signatures.
• crossgen'd thunks
  • R2R webcil which even pure interp would load module to be able to install those thunks
  • LLVM linkable .o file that dotnet.native.wasm would link

Both options are incomplete because we don't pre-create thunks for signatures in the app assemblies.
Doing so means running crossgen in the dev-loop too.

None of this is on critical path for me, to unblock Blazor on R2R. I'm closing this and we will re-consider later.

I'm back to #132926

cc @jkotas@davidwrighton

[jkotas]

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

Right. It means that you should not need any R2R->interpreter thunks (there is no R2R code), managed->managed calls should be going through interpreter without any intermediate thunks, and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

I'm back to #132926

The change in #132926 is dead-end.

[pavelsavara]

It means that you should not need any R2R->interpreter thunks (there is no R2R code)

Correct no R2R code.

and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

That's what #132926 is generating.
I think the subject of that PR is confusion, it should speak about "interp-to-native-entrypoint" thunks rather than "interp-to-R2R" thunks. I will update that PR.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable — from the interpreter and from native/host code — which requires a real, per-signature wasm function (the thunk) that marshals the typed args and re-enters the interpreter.

• Default constructors — callhelpers.cpp:581: RuntimeHelpers.CallDefaultConstructor does a calli ctorCode. In pure interp that helper runs interpreted, and its calli calls through _pActualCode = the thunk.
• Finalizers — comutilnative.cpp:797: RunFinalizers invokes the finalizer via its function pointer.
• Class constructors — methodtable.cpp:3580: CallClassConstructor invokes the cctor via its function pointer.
• Plus the original CI failure: Dictionary.Add materializing an interpreted comparer's entry point.

[jkotas]

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable

That's not correct. Pure interpreter is expected to use portable-entry-point for managed method delegate. This portable-entry-point does not have to have _pActualCode filled in when the thunk does not exist.

runtime/src/coreclr/vm/interpexec.cpp

Lines 3355 to 3356 in 04a9b1a

	if (PortableEntryPoint::PrefersInterpreterEntryPoint(calliFunctionPointer) || !PortableEntryPoint::HasNativeEntryPoint(calliFunctionPointer))
	gotoCALL_INTERP_METHOD;

is expected to detect this situation and keep interpreting the call without ever calling via _pActualCode.

[jkotas]

Do you see the condition that I have linked to be false in the problematic cases? There are multiple clones of this condition in interpexec.cpp handling different types of calls.

[pavelsavara]

Addresses @jkotas's feedback on #132926: rather than grow another static table of hand-written R2R-to-interpreter thunks, delete them and rely on the ones crossgen2 already emits.

What

The R2R-to-interpreter transition thunks were a hand-written table in vm/wasm/helpers.cpp (g_wasmPortableEntryPointThunks + the CallInterpreter_* functions). crossgen2 already emits these thunks into each R2R image (WasmR2RToInterpreterThunkNode, keyed "I"+signature, from #127483), and the runtime discovers them by string via LookupPregeneratedThunkByString. The static table was therefore a buggy, incomplete duplicate that shadowed the correct crossgen2 thunks — it was checked first, yet had no float/double-return shape, among others.

This removes the table and routes LookupPortableEntryPointThunk solely through the R2R string hash. Pure interpreter keeps working via the existing deferral path (EnsurePortableEntryPointIsCallableFromR2R → AddPendingPortableEntryPointThunk, resolved when an R2R module loads). helpers.cpp: −368 / +5.

Test

Adds src/tests/readytorun/wasm/WasmInterpreterTransitions, exercising both transition directions across struct (S8/S12/S16), scalar, void, and float/double returns. [BypassReadyToRun] + composite R2R ensures every cross-call actually hits a thunk (a wrong parameter order still type-checks under call_indirect, so the cases assert pinned values).

Validation (local, Windows host)

• Browser CoreCLR: WasmInterpreterTransitions passes (Expected 100 / Actual 100).
• Sibling browser R2R tests pass: WasmR2RStructAlignment, Runtime_131640.
• WasmArgumentLayoutTests (crossgen2 lowering, unchanged here): 52 / 52.
• console-node CoreCLR sample runs clean.
• helpers.cpp compiles for both browser and wasi (the wasi target runtime builds).

Commits

1. [wasm] Treat wasi as a cross-target in the Windows build scripts — a separable wasi-on-Windows build fix (also carried in [wasm] Generate the native-entry-point-to-interpreter thunk table #132926) so the wasi CoreCLR build configures on a Windows host. This is only one of the two separable wasi build fixes; the configureplatform.cmake cross-components fix is not included, so a full wasi build is not green from this PR alone. Can be split into its own PR if preferred.
2. [wasm] Delete hand-written R2R-to-interpreter thunks; use crossgen2's.

Draft while gathering CI signal.

Note

This PR description was generated with AI assistance.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[pavelsavara]

Why the pregenerated portable-entry-point thunk table cannot be deleted

The R2R→interpreter thunk is needed whenever a caller reaches an interpreted method through a materialized native entry point — i.e. any call_indirect: ldftn/delegate/virtual dispatch, plus every R2R→interpreter call. On wasm that entry point is an index into __indirect_function_table, and the thunk is the function that builds the interpreter frame and enters it with the right signature.

crossgen2 emits these thunks (WasmR2RToInterpreterThunkNode, keyed 'I'+sig) into each R2R image, discovered at runtime via LookupPregeneratedThunkByString. That source exists only for shapes a loaded, crossgen'd module rooted.

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

But the interpreter still needs a portable entry point the instant managed code takes a delegate/function-pointer to an interpreted method.

This leaves us with

• pre-generated C thunks for known signatures.
• crossgen'd thunks
  • R2R webcil which even pure interp would load module to be able to install those thunks
  • LLVM linkable .o file that dotnet.native.wasm would link

Both options are incomplete because we don't pre-create thunks for signatures in the app assemblies.
Doing so means running crossgen in the dev-loop too.

None of this is on critical path for me, to unblock Blazor on R2R. I'm closing this and we will re-consider later.

I'm back to #132926

cc @jkotas@davidwrighton

[jkotas]

Pure interpreter loads zero R2R images. With DOTNET_ReadyToRun=0, or simply when nothing was crossgen'd (dev inner-loop), no R2R module is present.

Right. It means that you should not need any R2R->interpreter thunks (there is no R2R code), managed->managed calls should be going through interpreter without any intermediate thunks, and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

I'm back to #132926

The change in #132926 is dead-end.

[pavelsavara]

It means that you should not need any R2R->interpreter thunks (there is no R2R code)

Correct no R2R code.

and managed<->native calls should be covered by thunks generated by the pre-generated C thunks.

That's what #132926 is generating.
I think the subject of that PR is confusion, it should speak about "interp-to-native-entrypoint" thunks rather than "interp-to-R2R" thunks. I will update that PR.

Can you share a few examples of situations that are causing problems once the hardcoded list of thunks is deleted?

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable — from the interpreter and from native/host code — which requires a real, per-signature wasm function (the thunk) that marshals the typed args and re-enters the interpreter.

• Default constructors — callhelpers.cpp:581: RuntimeHelpers.CallDefaultConstructor does a calli ctorCode. In pure interp that helper runs interpreted, and its calli calls through _pActualCode = the thunk.
• Finalizers — comutilnative.cpp:797: RunFinalizers invokes the finalizer via its function pointer.
• Class constructors — methodtable.cpp:3580: CallClassConstructor invokes the cctor via its function pointer.
• Plus the original CI failure: Dictionary.Add materializing an interpreted comparer's entry point.

[jkotas]

On wasm a native function pointer is a typed index into the function table. Even a pure interpreter must (A) convert a managed method (delegate / ldftn) into such a native pointer, and (B) have that pointer be callable

That's not correct. Pure interpreter is expected to use portable-entry-point for managed method delegate. This portable-entry-point does not have to have _pActualCode filled in when the thunk does not exist.

runtime/src/coreclr/vm/interpexec.cpp

Lines 3355 to 3356 in 04a9b1a

	if (PortableEntryPoint::PrefersInterpreterEntryPoint(calliFunctionPointer) || !PortableEntryPoint::HasNativeEntryPoint(calliFunctionPointer))
	gotoCALL_INTERP_METHOD;

is expected to detect this situation and keep interpreting the call without ever calling via _pActualCode.

[jkotas]

Do you see the condition that I have linked to be false in the problematic cases? There are multiple clones of this condition in interpexec.cpp handling different types of calls.