P/Invokes backed by transient IL by jkoritzinsky · Pull Request #126509 · dotnet/runtime

jkoritzinsky · 2026-04-03T16:42:29Z

This PR changes non-varargs P/Invokes to be backed by transient IL instead of by an IL stub.

This change removes 1 DynamicMethodDesc per P/Invoke and removes some interpreter workarounds we had for portable entrypoints (skipping the frame between the P/Invoke and the IL stub for perf) and Swift (ensuring we propagate back the SwiftError register reliably).

This change does not enable Tiered Compilation for P/Invoke methods. They are still considered not tierable and not eligible for ReJIT.

It also reverts #124579 as that work is no longer necessary now that regular P/Invokes are no longer using IL stubs.

…ause construction PInvokeStubLinker previously managed try-catch-finally blocks by manually creating labels, computing offsets, and constructing ILStubEHClause records. ILCodeStream already provides BeginTryBlock/EndTryBlock/BeginCatchBlock/EndCatchBlock/ BeginFinallyBlock/EndFinallyBlock APIs that handle this automatically. Changes: - Move m_buildingEHClauses and m_finishedEHClauses from ILCodeStream to ILStubLinker so EH clauses can span multiple code streams (the PInvoke stub's try-finally begins on the Marshal stream and ends on Cleanup). - Relax BeginHandler assertion to allow calling before EndTryBlock, since the finally handler may begin on a different stream than the try body. - Convert PInvokeStubLinker::Begin to use BeginTryBlock. - Convert SetCleanupNeeded to use BeginFinallyBlock instead of manually creating the cleanup finally begin label. - Convert PInvokeStubLinker::End to use EndTryBlock/EndFinallyBlock instead of manually creating try-end and finally-end labels. - Convert EmitExceptionHandler to use EndTryBlock/BeginCatchBlock/ EndCatchBlock instead of manual label management. - Replace manual EH clause construction (AppendEHClause, PopulateEHSect, GetCleanupFinallyOffsets) with ILStubLinker::GetNumEHClauses and WriteEHClauses. - Add ILStubLinker::GetEHClause for extracting resolved clause info for logging and ETW. - Remove PInvokeStubLinker::ClearCode override and manual EH label fields (m_pCleanupTryBeginLabel, m_pCleanupTryEndLabel, m_pCleanupFinallyBeginLabel, m_pCleanupFinallyEndLabel). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…t IL APIs are shaped

… stub path

This is no longer necessary as non-vararg forward P/Invokes are now truly non-shared and don't go through the ILStubCache infrastructure at all.

dotnet-policy-service · 2026-04-03T16:43:42Z

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

Copilot

Pull request overview

This PR changes CoreCLR’s handling of non-varargs P/Invokes to be implemented via transient IL rather than IL stubs, reducing per-P/Invoke stub overhead and removing related interpreter/workaround paths. It also reworks IL stub EH-clause tracking to support try/handler spans across multiple ILCodeStreams, and updates various call sites to reflect the new P/Invoke execution model.

Changes:

Switch non-varargs P/Invokes to transient-IL-backed implementations and adjust prestub/code-prep paths accordingly.
Move EH clause tracking from ILCodeStream into ILStubLinker, enabling cross-stream try/finally and try/catch constructs.
Update IL stub resolver finalization to accept configurable JIT flags and simplify EH section emission/consumption.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/vm/stubgen.h	Moves EH clause tracking ownership to `ILStubLinker`; adds `GetEHClause()` API.
src/coreclr/vm/stubgen.cpp	Updates EH tracking usage across streams; adds resolved EH-clause extraction; clears EH arrays on `ClearCode()`.
src/coreclr/vm/prestub.cpp	Routes non-varargs P/Invokes through `PrepareInitialCode` + explicit P/Invoke target resolution; varargs still use stubs.
src/coreclr/vm/method.cpp	Treats non-varargs P/Invokes as “may have native code”; explicitly excludes P/Invoke from tiered compilation eligibility; changes x86 stack arg sizing path.
src/coreclr/vm/jitinterface.cpp	Treats P/Invokes like IL/dynamic methods for `getMethodInfo` when no IL header is present.
src/coreclr/vm/ilstubresolver.h	Extends `FinalizeILStub` to take `CORJIT_FLAGS` (defaulting to `CORJIT_FLAG_IL_STUB`).
src/coreclr/vm/ilstubresolver.cpp	Uses passed-in JIT flags instead of hardcoding IL-stub flags.
src/coreclr/vm/dllimport.h	Adds APIs for transient-IL P/Invoke generation and for resolving targets; removes now-unused flag helpers.
src/coreclr/vm/dllimport.cpp	Implements transient IL generation for P/Invoke; refactors EH handling and stub finalization; updates vararg P/Invoke stub flow.
src/coreclr/inc/CrstTypes.def	Adjusts `ILStubGen` lock ordering metadata.

jkotas · 2026-04-03T17:31:03Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

AaronRobinsonMSFT · 2026-04-03T18:20:36Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

This is an important thing to check. When the transient IL logic was written we worked to make it "natural" so that from the JIT's perspective it has no clue where the IL comes from. This meant all the UnsafeAccessor functions just got inlined due to their size. Unless something has changed the inlining will happen using the same logic as any other IL JIT logic. This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

This is a long way of saying, we need to seriously think about making all of these inlinable as it could be a very distruptive change. I'm not sure which side I'd come down on now since we have LibraryImport.

jkotas · 2026-04-03T18:39:29Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

AaronRobinsonMSFT · 2026-04-03T20:27:08Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.
The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

Ugh. Why do I keep making this bad assumption. I need a brick to the head or something.

Copilot

Pull request overview

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

…-no-stub

… paths that resolve P/Invokes for the cases that they handle.

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

…time into pinvoke-no-stub

jkoritzinsky · 2026-04-21T00:07:37Z

/ba-g wasm failure is known (addressed by #127177)

…ke method (#127660) We didn't report these transitions when they were triggered from ILStubs because they already explicitly do this. Following the change of using transient IL belonging to the actual PInvoke method rather than separate ILStub methods (which should contain the same logic as the ILStub used to), we would now report the same event twice. We need therefore to also ignore the case where we are doing a PInvoke call from an actual PInvoke method. Fixes src/tests/profiler/transitions/transitions.csproj which regressed after #126509 on interpreter.

…es (#128257) ## Description #125177 implemented Swift calling convention detection in the interpreter's calli cookie generation. It inspects m_pMethodBeingCompiled->IsILStub() and walks the IL stub resolver to its StubTargetMethodDesc. This worked when forward P/Invokes were compiled as separate IL-stub DynamicMethodDescs. #126509 changed P/Invoke compilation: the PInvokeMethodDesc itself now carries the transient IL with the calli to the native target. MethodDesc::IsILStub() returns true only for DynamicMethodDesc, so IsILStub() returns false for a transient-IL P/Invoke and pContextMD stays NULL. With no context MD, CallStubGenerator::ComputeCallStub cannot enter either of its Swift detection branches. It falls through to the generic calling convention switch, leaves m_isSwiftCallConv = false, and: Never calls RewriteSignatureForSwiftLowering, so the [ref SwiftError, ref SwiftError] validation never throws InvalidProgramException. Generates a generic stub that does not preserve x21 across the native call, so SwiftError is lost on return. ## Fix In CInterpreterJitInfo::GetCookieForInterpreterCalliSig, also pass the method being compiled as pContextMD when it is a P/Invoke. The IsPInvoke branch already in ComputeCallStub then detects the Swift calling convention via PInvoke::GetCallingConvention_IgnoreErrors. Fixes#127897Fixes#127898 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkoritzinsky · 2026-04-03T16:42:29Z

This PR changes non-varargs P/Invokes to be backed by transient IL instead of by an IL stub.

This change removes 1 DynamicMethodDesc per P/Invoke and removes some interpreter workarounds we had for portable entrypoints (skipping the frame between the P/Invoke and the IL stub for perf) and Swift (ensuring we propagate back the SwiftError register reliably).

This change does not enable Tiered Compilation for P/Invoke methods. They are still considered not tierable and not eligible for ReJIT.

It also reverts #124579 as that work is no longer necessary now that regular P/Invokes are no longer using IL stubs.

…ause construction PInvokeStubLinker previously managed try-catch-finally blocks by manually creating labels, computing offsets, and constructing ILStubEHClause records. ILCodeStream already provides BeginTryBlock/EndTryBlock/BeginCatchBlock/EndCatchBlock/ BeginFinallyBlock/EndFinallyBlock APIs that handle this automatically. Changes: - Move m_buildingEHClauses and m_finishedEHClauses from ILCodeStream to ILStubLinker so EH clauses can span multiple code streams (the PInvoke stub's try-finally begins on the Marshal stream and ends on Cleanup). - Relax BeginHandler assertion to allow calling before EndTryBlock, since the finally handler may begin on a different stream than the try body. - Convert PInvokeStubLinker::Begin to use BeginTryBlock. - Convert SetCleanupNeeded to use BeginFinallyBlock instead of manually creating the cleanup finally begin label. - Convert PInvokeStubLinker::End to use EndTryBlock/EndFinallyBlock instead of manually creating try-end and finally-end labels. - Convert EmitExceptionHandler to use EndTryBlock/BeginCatchBlock/ EndCatchBlock instead of manual label management. - Replace manual EH clause construction (AppendEHClause, PopulateEHSect, GetCleanupFinallyOffsets) with ILStubLinker::GetNumEHClauses and WriteEHClauses. - Add ILStubLinker::GetEHClause for extracting resolved clause info for logging and ETW. - Remove PInvokeStubLinker::ClearCode override and manual EH label fields (m_pCleanupTryBeginLabel, m_pCleanupTryEndLabel, m_pCleanupFinallyBeginLabel, m_pCleanupFinallyEndLabel). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…t IL APIs are shaped

… stub path

This is no longer necessary as non-vararg forward P/Invokes are now truly non-shared and don't go through the ILStubCache infrastructure at all.

dotnet-policy-service · 2026-04-03T16:43:42Z

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

Copilot

Pull request overview

This PR changes CoreCLR’s handling of non-varargs P/Invokes to be implemented via transient IL rather than IL stubs, reducing per-P/Invoke stub overhead and removing related interpreter/workaround paths. It also reworks IL stub EH-clause tracking to support try/handler spans across multiple ILCodeStreams, and updates various call sites to reflect the new P/Invoke execution model.

Changes:

Switch non-varargs P/Invokes to transient-IL-backed implementations and adjust prestub/code-prep paths accordingly.
Move EH clause tracking from ILCodeStream into ILStubLinker, enabling cross-stream try/finally and try/catch constructs.
Update IL stub resolver finalization to accept configurable JIT flags and simplify EH section emission/consumption.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/vm/stubgen.h	Moves EH clause tracking ownership to `ILStubLinker`; adds `GetEHClause()` API.
src/coreclr/vm/stubgen.cpp	Updates EH tracking usage across streams; adds resolved EH-clause extraction; clears EH arrays on `ClearCode()`.
src/coreclr/vm/prestub.cpp	Routes non-varargs P/Invokes through `PrepareInitialCode` + explicit P/Invoke target resolution; varargs still use stubs.
src/coreclr/vm/method.cpp	Treats non-varargs P/Invokes as “may have native code”; explicitly excludes P/Invoke from tiered compilation eligibility; changes x86 stack arg sizing path.
src/coreclr/vm/jitinterface.cpp	Treats P/Invokes like IL/dynamic methods for `getMethodInfo` when no IL header is present.
src/coreclr/vm/ilstubresolver.h	Extends `FinalizeILStub` to take `CORJIT_FLAGS` (defaulting to `CORJIT_FLAG_IL_STUB`).
src/coreclr/vm/ilstubresolver.cpp	Uses passed-in JIT flags instead of hardcoding IL-stub flags.
src/coreclr/vm/dllimport.h	Adds APIs for transient-IL P/Invoke generation and for resolving targets; removes now-unused flag helpers.
src/coreclr/vm/dllimport.cpp	Implements transient IL generation for P/Invoke; refactors EH handling and stub finalization; updates vararg P/Invoke stub flow.
src/coreclr/inc/CrstTypes.def	Adjusts `ILStubGen` lock ordering metadata.

jkotas · 2026-04-03T17:31:03Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

AaronRobinsonMSFT · 2026-04-03T18:20:36Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

This is an important thing to check. When the transient IL logic was written we worked to make it "natural" so that from the JIT's perspective it has no clue where the IL comes from. This meant all the UnsafeAccessor functions just got inlined due to their size. Unless something has changed the inlining will happen using the same logic as any other IL JIT logic. This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

This is a long way of saying, we need to seriously think about making all of these inlinable as it could be a very distruptive change. I'm not sure which side I'd come down on now since we have LibraryImport.

jkotas · 2026-04-03T18:39:29Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

AaronRobinsonMSFT · 2026-04-03T20:27:08Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.
The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

Ugh. Why do I keep making this bad assumption. I need a brick to the head or something.

Copilot

Pull request overview

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

…-no-stub

… paths that resolve P/Invokes for the cases that they handle.

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

…time into pinvoke-no-stub

jkoritzinsky · 2026-04-21T00:07:37Z

/ba-g wasm failure is known (addressed by #127177)

…ke method (#127660) We didn't report these transitions when they were triggered from ILStubs because they already explicitly do this. Following the change of using transient IL belonging to the actual PInvoke method rather than separate ILStub methods (which should contain the same logic as the ILStub used to), we would now report the same event twice. We need therefore to also ignore the case where we are doing a PInvoke call from an actual PInvoke method. Fixes src/tests/profiler/transitions/transitions.csproj which regressed after #126509 on interpreter.

…es (#128257) ## Description #125177 implemented Swift calling convention detection in the interpreter's calli cookie generation. It inspects m_pMethodBeingCompiled->IsILStub() and walks the IL stub resolver to its StubTargetMethodDesc. This worked when forward P/Invokes were compiled as separate IL-stub DynamicMethodDescs. #126509 changed P/Invoke compilation: the PInvokeMethodDesc itself now carries the transient IL with the calli to the native target. MethodDesc::IsILStub() returns true only for DynamicMethodDesc, so IsILStub() returns false for a transient-IL P/Invoke and pContextMD stays NULL. With no context MD, CallStubGenerator::ComputeCallStub cannot enter either of its Swift detection branches. It falls through to the generic calling convention switch, leaves m_isSwiftCallConv = false, and: Never calls RewriteSignatureForSwiftLowering, so the [ref SwiftError, ref SwiftError] validation never throws InvalidProgramException. Generates a generic stub that does not preserve x21 across the native call, so SwiftError is lost on return. ## Fix In CInterpreterJitInfo::GetCookieForInterpreterCalliSig, also pass the method being compiled as pContextMD when it is a P/Invoke. The IsPInvoke branch already in ComputeCallStub then detects the Swift calling convention via PInvoke::GetCallingConvention_IgnoreErrors. Fixes#127897Fixes#127898 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkoritzinsky · 2026-04-03T16:42:29Z

This PR changes non-varargs P/Invokes to be backed by transient IL instead of by an IL stub.

This change removes 1 DynamicMethodDesc per P/Invoke and removes some interpreter workarounds we had for portable entrypoints (skipping the frame between the P/Invoke and the IL stub for perf) and Swift (ensuring we propagate back the SwiftError register reliably).

This change does not enable Tiered Compilation for P/Invoke methods. They are still considered not tierable and not eligible for ReJIT.

It also reverts #124579 as that work is no longer necessary now that regular P/Invokes are no longer using IL stubs.

…ause construction PInvokeStubLinker previously managed try-catch-finally blocks by manually creating labels, computing offsets, and constructing ILStubEHClause records. ILCodeStream already provides BeginTryBlock/EndTryBlock/BeginCatchBlock/EndCatchBlock/ BeginFinallyBlock/EndFinallyBlock APIs that handle this automatically. Changes: - Move m_buildingEHClauses and m_finishedEHClauses from ILCodeStream to ILStubLinker so EH clauses can span multiple code streams (the PInvoke stub's try-finally begins on the Marshal stream and ends on Cleanup). - Relax BeginHandler assertion to allow calling before EndTryBlock, since the finally handler may begin on a different stream than the try body. - Convert PInvokeStubLinker::Begin to use BeginTryBlock. - Convert SetCleanupNeeded to use BeginFinallyBlock instead of manually creating the cleanup finally begin label. - Convert PInvokeStubLinker::End to use EndTryBlock/EndFinallyBlock instead of manually creating try-end and finally-end labels. - Convert EmitExceptionHandler to use EndTryBlock/BeginCatchBlock/ EndCatchBlock instead of manual label management. - Replace manual EH clause construction (AppendEHClause, PopulateEHSect, GetCleanupFinallyOffsets) with ILStubLinker::GetNumEHClauses and WriteEHClauses. - Add ILStubLinker::GetEHClause for extracting resolved clause info for logging and ETW. - Remove PInvokeStubLinker::ClearCode override and manual EH label fields (m_pCleanupTryBeginLabel, m_pCleanupTryEndLabel, m_pCleanupFinallyBeginLabel, m_pCleanupFinallyEndLabel). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…t IL APIs are shaped

… stub path

This is no longer necessary as non-vararg forward P/Invokes are now truly non-shared and don't go through the ILStubCache infrastructure at all.

dotnet-policy-service · 2026-04-03T16:43:42Z

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

Copilot

Pull request overview

This PR changes CoreCLR’s handling of non-varargs P/Invokes to be implemented via transient IL rather than IL stubs, reducing per-P/Invoke stub overhead and removing related interpreter/workaround paths. It also reworks IL stub EH-clause tracking to support try/handler spans across multiple ILCodeStreams, and updates various call sites to reflect the new P/Invoke execution model.

Changes:

Switch non-varargs P/Invokes to transient-IL-backed implementations and adjust prestub/code-prep paths accordingly.
Move EH clause tracking from ILCodeStream into ILStubLinker, enabling cross-stream try/finally and try/catch constructs.
Update IL stub resolver finalization to accept configurable JIT flags and simplify EH section emission/consumption.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/vm/stubgen.h	Moves EH clause tracking ownership to `ILStubLinker`; adds `GetEHClause()` API.
src/coreclr/vm/stubgen.cpp	Updates EH tracking usage across streams; adds resolved EH-clause extraction; clears EH arrays on `ClearCode()`.
src/coreclr/vm/prestub.cpp	Routes non-varargs P/Invokes through `PrepareInitialCode` + explicit P/Invoke target resolution; varargs still use stubs.
src/coreclr/vm/method.cpp	Treats non-varargs P/Invokes as “may have native code”; explicitly excludes P/Invoke from tiered compilation eligibility; changes x86 stack arg sizing path.
src/coreclr/vm/jitinterface.cpp	Treats P/Invokes like IL/dynamic methods for `getMethodInfo` when no IL header is present.
src/coreclr/vm/ilstubresolver.h	Extends `FinalizeILStub` to take `CORJIT_FLAGS` (defaulting to `CORJIT_FLAG_IL_STUB`).
src/coreclr/vm/ilstubresolver.cpp	Uses passed-in JIT flags instead of hardcoding IL-stub flags.
src/coreclr/vm/dllimport.h	Adds APIs for transient-IL P/Invoke generation and for resolving targets; removes now-unused flag helpers.
src/coreclr/vm/dllimport.cpp	Implements transient IL generation for P/Invoke; refactors EH handling and stub finalization; updates vararg P/Invoke stub flow.
src/coreclr/inc/CrstTypes.def	Adjusts `ILStubGen` lock ordering metadata.

jkotas · 2026-04-03T17:31:03Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

AaronRobinsonMSFT · 2026-04-03T18:20:36Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

This is an important thing to check. When the transient IL logic was written we worked to make it "natural" so that from the JIT's perspective it has no clue where the IL comes from. This meant all the UnsafeAccessor functions just got inlined due to their size. Unless something has changed the inlining will happen using the same logic as any other IL JIT logic. This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

This is a long way of saying, we need to seriously think about making all of these inlinable as it could be a very distruptive change. I'm not sure which side I'd come down on now since we have LibraryImport.

jkotas · 2026-04-03T18:39:29Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

AaronRobinsonMSFT · 2026-04-03T20:27:08Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.
The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

Ugh. Why do I keep making this bad assumption. I need a brick to the head or something.

Copilot

Pull request overview

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

…-no-stub

… paths that resolve P/Invokes for the cases that they handle.

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

…time into pinvoke-no-stub

jkoritzinsky · 2026-04-21T00:07:37Z

/ba-g wasm failure is known (addressed by #127177)

…ke method (#127660) We didn't report these transitions when they were triggered from ILStubs because they already explicitly do this. Following the change of using transient IL belonging to the actual PInvoke method rather than separate ILStub methods (which should contain the same logic as the ILStub used to), we would now report the same event twice. We need therefore to also ignore the case where we are doing a PInvoke call from an actual PInvoke method. Fixes src/tests/profiler/transitions/transitions.csproj which regressed after #126509 on interpreter.

…es (#128257) ## Description #125177 implemented Swift calling convention detection in the interpreter's calli cookie generation. It inspects m_pMethodBeingCompiled->IsILStub() and walks the IL stub resolver to its StubTargetMethodDesc. This worked when forward P/Invokes were compiled as separate IL-stub DynamicMethodDescs. #126509 changed P/Invoke compilation: the PInvokeMethodDesc itself now carries the transient IL with the calli to the native target. MethodDesc::IsILStub() returns true only for DynamicMethodDesc, so IsILStub() returns false for a transient-IL P/Invoke and pContextMD stays NULL. With no context MD, CallStubGenerator::ComputeCallStub cannot enter either of its Swift detection branches. It falls through to the generic calling convention switch, leaves m_isSwiftCallConv = false, and: Never calls RewriteSignatureForSwiftLowering, so the [ref SwiftError, ref SwiftError] validation never throws InvalidProgramException. Generates a generic stub that does not preserve x21 across the native call, so SwiftError is lost on return. ## Fix In CInterpreterJitInfo::GetCookieForInterpreterCalliSig, also pass the method being compiled as pContextMD when it is a P/Invoke. The IsPInvoke branch already in ComputeCallStub then detects the Swift calling convention via PInvoke::GetCallingConvention_IgnoreErrors. Fixes#127897Fixes#127898 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkoritzinsky · 2026-04-03T16:42:29Z

This PR changes non-varargs P/Invokes to be backed by transient IL instead of by an IL stub.

This change removes 1 DynamicMethodDesc per P/Invoke and removes some interpreter workarounds we had for portable entrypoints (skipping the frame between the P/Invoke and the IL stub for perf) and Swift (ensuring we propagate back the SwiftError register reliably).

This change does not enable Tiered Compilation for P/Invoke methods. They are still considered not tierable and not eligible for ReJIT.

It also reverts #124579 as that work is no longer necessary now that regular P/Invokes are no longer using IL stubs.

…ause construction PInvokeStubLinker previously managed try-catch-finally blocks by manually creating labels, computing offsets, and constructing ILStubEHClause records. ILCodeStream already provides BeginTryBlock/EndTryBlock/BeginCatchBlock/EndCatchBlock/ BeginFinallyBlock/EndFinallyBlock APIs that handle this automatically. Changes: - Move m_buildingEHClauses and m_finishedEHClauses from ILCodeStream to ILStubLinker so EH clauses can span multiple code streams (the PInvoke stub's try-finally begins on the Marshal stream and ends on Cleanup). - Relax BeginHandler assertion to allow calling before EndTryBlock, since the finally handler may begin on a different stream than the try body. - Convert PInvokeStubLinker::Begin to use BeginTryBlock. - Convert SetCleanupNeeded to use BeginFinallyBlock instead of manually creating the cleanup finally begin label. - Convert PInvokeStubLinker::End to use EndTryBlock/EndFinallyBlock instead of manually creating try-end and finally-end labels. - Convert EmitExceptionHandler to use EndTryBlock/BeginCatchBlock/ EndCatchBlock instead of manual label management. - Replace manual EH clause construction (AppendEHClause, PopulateEHSect, GetCleanupFinallyOffsets) with ILStubLinker::GetNumEHClauses and WriteEHClauses. - Add ILStubLinker::GetEHClause for extracting resolved clause info for logging and ETW. - Remove PInvokeStubLinker::ClearCode override and manual EH label fields (m_pCleanupTryBeginLabel, m_pCleanupTryEndLabel, m_pCleanupFinallyBeginLabel, m_pCleanupFinallyEndLabel). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…t IL APIs are shaped

… stub path

This is no longer necessary as non-vararg forward P/Invokes are now truly non-shared and don't go through the ILStubCache infrastructure at all.

dotnet-policy-service · 2026-04-03T16:43:42Z

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

Copilot

Pull request overview

This PR changes CoreCLR’s handling of non-varargs P/Invokes to be implemented via transient IL rather than IL stubs, reducing per-P/Invoke stub overhead and removing related interpreter/workaround paths. It also reworks IL stub EH-clause tracking to support try/handler spans across multiple ILCodeStreams, and updates various call sites to reflect the new P/Invoke execution model.

Changes:

Switch non-varargs P/Invokes to transient-IL-backed implementations and adjust prestub/code-prep paths accordingly.
Move EH clause tracking from ILCodeStream into ILStubLinker, enabling cross-stream try/finally and try/catch constructs.
Update IL stub resolver finalization to accept configurable JIT flags and simplify EH section emission/consumption.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/vm/stubgen.h	Moves EH clause tracking ownership to `ILStubLinker`; adds `GetEHClause()` API.
src/coreclr/vm/stubgen.cpp	Updates EH tracking usage across streams; adds resolved EH-clause extraction; clears EH arrays on `ClearCode()`.
src/coreclr/vm/prestub.cpp	Routes non-varargs P/Invokes through `PrepareInitialCode` + explicit P/Invoke target resolution; varargs still use stubs.
src/coreclr/vm/method.cpp	Treats non-varargs P/Invokes as “may have native code”; explicitly excludes P/Invoke from tiered compilation eligibility; changes x86 stack arg sizing path.
src/coreclr/vm/jitinterface.cpp	Treats P/Invokes like IL/dynamic methods for `getMethodInfo` when no IL header is present.
src/coreclr/vm/ilstubresolver.h	Extends `FinalizeILStub` to take `CORJIT_FLAGS` (defaulting to `CORJIT_FLAG_IL_STUB`).
src/coreclr/vm/ilstubresolver.cpp	Uses passed-in JIT flags instead of hardcoding IL-stub flags.
src/coreclr/vm/dllimport.h	Adds APIs for transient-IL P/Invoke generation and for resolving targets; removes now-unused flag helpers.
src/coreclr/vm/dllimport.cpp	Implements transient IL generation for P/Invoke; refactors EH handling and stub finalization; updates vararg P/Invoke stub flow.
src/coreclr/inc/CrstTypes.def	Adjusts `ILStubGen` lock ordering metadata.

jkotas · 2026-04-03T17:31:03Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

AaronRobinsonMSFT · 2026-04-03T18:20:36Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

This is an important thing to check. When the transient IL logic was written we worked to make it "natural" so that from the JIT's perspective it has no clue where the IL comes from. This meant all the UnsafeAccessor functions just got inlined due to their size. Unless something has changed the inlining will happen using the same logic as any other IL JIT logic. This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

This is a long way of saying, we need to seriously think about making all of these inlinable as it could be a very distruptive change. I'm not sure which side I'd come down on now since we have LibraryImport.

jkotas · 2026-04-03T18:39:29Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

AaronRobinsonMSFT · 2026-04-03T20:27:08Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.
The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

Ugh. Why do I keep making this bad assumption. I need a brick to the head or something.

Copilot

Pull request overview

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

…-no-stub

… paths that resolve P/Invokes for the cases that they handle.

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

…time into pinvoke-no-stub

jkoritzinsky · 2026-04-21T00:07:37Z

/ba-g wasm failure is known (addressed by #127177)

…ke method (#127660) We didn't report these transitions when they were triggered from ILStubs because they already explicitly do this. Following the change of using transient IL belonging to the actual PInvoke method rather than separate ILStub methods (which should contain the same logic as the ILStub used to), we would now report the same event twice. We need therefore to also ignore the case where we are doing a PInvoke call from an actual PInvoke method. Fixes src/tests/profiler/transitions/transitions.csproj which regressed after #126509 on interpreter.

…es (#128257) ## Description #125177 implemented Swift calling convention detection in the interpreter's calli cookie generation. It inspects m_pMethodBeingCompiled->IsILStub() and walks the IL stub resolver to its StubTargetMethodDesc. This worked when forward P/Invokes were compiled as separate IL-stub DynamicMethodDescs. #126509 changed P/Invoke compilation: the PInvokeMethodDesc itself now carries the transient IL with the calli to the native target. MethodDesc::IsILStub() returns true only for DynamicMethodDesc, so IsILStub() returns false for a transient-IL P/Invoke and pContextMD stays NULL. With no context MD, CallStubGenerator::ComputeCallStub cannot enter either of its Swift detection branches. It falls through to the generic calling convention switch, leaves m_isSwiftCallConv = false, and: Never calls RewriteSignatureForSwiftLowering, so the [ref SwiftError, ref SwiftError] validation never throws InvalidProgramException. Generates a generic stub that does not preserve x21 across the native call, so SwiftError is lost on return. ## Fix In CInterpreterJitInfo::GetCookieForInterpreterCalliSig, also pass the method being compiled as pContextMD when it is a P/Invoke. The IsPInvoke branch already in ComputeCallStub then detects the Swift calling convention via PInvoke::GetCallingConvention_IgnoreErrors. Fixes#127897Fixes#127898 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkoritzinsky · 2026-04-03T16:42:29Z

This PR changes non-varargs P/Invokes to be backed by transient IL instead of by an IL stub.

This change removes 1 DynamicMethodDesc per P/Invoke and removes some interpreter workarounds we had for portable entrypoints (skipping the frame between the P/Invoke and the IL stub for perf) and Swift (ensuring we propagate back the SwiftError register reliably).

This change does not enable Tiered Compilation for P/Invoke methods. They are still considered not tierable and not eligible for ReJIT.

It also reverts #124579 as that work is no longer necessary now that regular P/Invokes are no longer using IL stubs.

…ause construction PInvokeStubLinker previously managed try-catch-finally blocks by manually creating labels, computing offsets, and constructing ILStubEHClause records. ILCodeStream already provides BeginTryBlock/EndTryBlock/BeginCatchBlock/EndCatchBlock/ BeginFinallyBlock/EndFinallyBlock APIs that handle this automatically. Changes: - Move m_buildingEHClauses and m_finishedEHClauses from ILCodeStream to ILStubLinker so EH clauses can span multiple code streams (the PInvoke stub's try-finally begins on the Marshal stream and ends on Cleanup). - Relax BeginHandler assertion to allow calling before EndTryBlock, since the finally handler may begin on a different stream than the try body. - Convert PInvokeStubLinker::Begin to use BeginTryBlock. - Convert SetCleanupNeeded to use BeginFinallyBlock instead of manually creating the cleanup finally begin label. - Convert PInvokeStubLinker::End to use EndTryBlock/EndFinallyBlock instead of manually creating try-end and finally-end labels. - Convert EmitExceptionHandler to use EndTryBlock/BeginCatchBlock/ EndCatchBlock instead of manual label management. - Replace manual EH clause construction (AppendEHClause, PopulateEHSect, GetCleanupFinallyOffsets) with ILStubLinker::GetNumEHClauses and WriteEHClauses. - Add ILStubLinker::GetEHClause for extracting resolved clause info for logging and ETW. - Remove PInvokeStubLinker::ClearCode override and manual EH label fields (m_pCleanupTryBeginLabel, m_pCleanupTryEndLabel, m_pCleanupFinallyBeginLabel, m_pCleanupFinallyEndLabel). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…t IL APIs are shaped

… stub path

This is no longer necessary as non-vararg forward P/Invokes are now truly non-shared and don't go through the ILStubCache infrastructure at all.

dotnet-policy-service · 2026-04-03T16:43:42Z

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

Copilot

Pull request overview

This PR changes CoreCLR’s handling of non-varargs P/Invokes to be implemented via transient IL rather than IL stubs, reducing per-P/Invoke stub overhead and removing related interpreter/workaround paths. It also reworks IL stub EH-clause tracking to support try/handler spans across multiple ILCodeStreams, and updates various call sites to reflect the new P/Invoke execution model.

Changes:

Switch non-varargs P/Invokes to transient-IL-backed implementations and adjust prestub/code-prep paths accordingly.
Move EH clause tracking from ILCodeStream into ILStubLinker, enabling cross-stream try/finally and try/catch constructs.
Update IL stub resolver finalization to accept configurable JIT flags and simplify EH section emission/consumption.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/vm/stubgen.h	Moves EH clause tracking ownership to `ILStubLinker`; adds `GetEHClause()` API.
src/coreclr/vm/stubgen.cpp	Updates EH tracking usage across streams; adds resolved EH-clause extraction; clears EH arrays on `ClearCode()`.
src/coreclr/vm/prestub.cpp	Routes non-varargs P/Invokes through `PrepareInitialCode` + explicit P/Invoke target resolution; varargs still use stubs.
src/coreclr/vm/method.cpp	Treats non-varargs P/Invokes as “may have native code”; explicitly excludes P/Invoke from tiered compilation eligibility; changes x86 stack arg sizing path.
src/coreclr/vm/jitinterface.cpp	Treats P/Invokes like IL/dynamic methods for `getMethodInfo` when no IL header is present.
src/coreclr/vm/ilstubresolver.h	Extends `FinalizeILStub` to take `CORJIT_FLAGS` (defaulting to `CORJIT_FLAG_IL_STUB`).
src/coreclr/vm/ilstubresolver.cpp	Uses passed-in JIT flags instead of hardcoding IL-stub flags.
src/coreclr/vm/dllimport.h	Adds APIs for transient-IL P/Invoke generation and for resolving targets; removes now-unused flag helpers.
src/coreclr/vm/dllimport.cpp	Implements transient IL generation for P/Invoke; refactors EH handling and stub finalization; updates vararg P/Invoke stub flow.
src/coreclr/inc/CrstTypes.def	Adjusts `ILStubGen` lock ordering metadata.

jkotas · 2026-04-03T17:31:03Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

AaronRobinsonMSFT · 2026-04-03T18:20:36Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

This is an important thing to check. When the transient IL logic was written we worked to make it "natural" so that from the JIT's perspective it has no clue where the IL comes from. This meant all the UnsafeAccessor functions just got inlined due to their size. Unless something has changed the inlining will happen using the same logic as any other IL JIT logic. This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

This is a long way of saying, we need to seriously think about making all of these inlinable as it could be a very distruptive change. I'm not sure which side I'd come down on now since we have LibraryImport.

jkotas · 2026-04-03T18:39:29Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

AaronRobinsonMSFT · 2026-04-03T20:27:08Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.
The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

Ugh. Why do I keep making this bad assumption. I need a brick to the head or something.

Copilot

Pull request overview

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

…-no-stub

… paths that resolve P/Invokes for the cases that they handle.

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

…time into pinvoke-no-stub

jkoritzinsky · 2026-04-21T00:07:37Z

/ba-g wasm failure is known (addressed by #127177)

…ke method (#127660) We didn't report these transitions when they were triggered from ILStubs because they already explicitly do this. Following the change of using transient IL belonging to the actual PInvoke method rather than separate ILStub methods (which should contain the same logic as the ILStub used to), we would now report the same event twice. We need therefore to also ignore the case where we are doing a PInvoke call from an actual PInvoke method. Fixes src/tests/profiler/transitions/transitions.csproj which regressed after #126509 on interpreter.

…es (#128257) ## Description #125177 implemented Swift calling convention detection in the interpreter's calli cookie generation. It inspects m_pMethodBeingCompiled->IsILStub() and walks the IL stub resolver to its StubTargetMethodDesc. This worked when forward P/Invokes were compiled as separate IL-stub DynamicMethodDescs. #126509 changed P/Invoke compilation: the PInvokeMethodDesc itself now carries the transient IL with the calli to the native target. MethodDesc::IsILStub() returns true only for DynamicMethodDesc, so IsILStub() returns false for a transient-IL P/Invoke and pContextMD stays NULL. With no context MD, CallStubGenerator::ComputeCallStub cannot enter either of its Swift detection branches. It falls through to the generic calling convention switch, leaves m_isSwiftCallConv = false, and: Never calls RewriteSignatureForSwiftLowering, so the [ref SwiftError, ref SwiftError] validation never throws InvalidProgramException. Generates a generic stub that does not preserve x21 across the native call, so SwiftError is lost on return. ## Fix In CInterpreterJitInfo::GetCookieForInterpreterCalliSig, also pass the method being compiled as pContextMD when it is a P/Invoke. The IsPInvoke branch already in ComputeCallStub then detects the Swift calling convention via PInvoke::GetCallingConvention_IgnoreErrors. Fixes#127897Fixes#127898 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkoritzinsky · 2026-04-03T16:42:29Z

This PR changes non-varargs P/Invokes to be backed by transient IL instead of by an IL stub.

This change removes 1 DynamicMethodDesc per P/Invoke and removes some interpreter workarounds we had for portable entrypoints (skipping the frame between the P/Invoke and the IL stub for perf) and Swift (ensuring we propagate back the SwiftError register reliably).

This change does not enable Tiered Compilation for P/Invoke methods. They are still considered not tierable and not eligible for ReJIT.

It also reverts #124579 as that work is no longer necessary now that regular P/Invokes are no longer using IL stubs.

…ause construction PInvokeStubLinker previously managed try-catch-finally blocks by manually creating labels, computing offsets, and constructing ILStubEHClause records. ILCodeStream already provides BeginTryBlock/EndTryBlock/BeginCatchBlock/EndCatchBlock/ BeginFinallyBlock/EndFinallyBlock APIs that handle this automatically. Changes: - Move m_buildingEHClauses and m_finishedEHClauses from ILCodeStream to ILStubLinker so EH clauses can span multiple code streams (the PInvoke stub's try-finally begins on the Marshal stream and ends on Cleanup). - Relax BeginHandler assertion to allow calling before EndTryBlock, since the finally handler may begin on a different stream than the try body. - Convert PInvokeStubLinker::Begin to use BeginTryBlock. - Convert SetCleanupNeeded to use BeginFinallyBlock instead of manually creating the cleanup finally begin label. - Convert PInvokeStubLinker::End to use EndTryBlock/EndFinallyBlock instead of manually creating try-end and finally-end labels. - Convert EmitExceptionHandler to use EndTryBlock/BeginCatchBlock/ EndCatchBlock instead of manual label management. - Replace manual EH clause construction (AppendEHClause, PopulateEHSect, GetCleanupFinallyOffsets) with ILStubLinker::GetNumEHClauses and WriteEHClauses. - Add ILStubLinker::GetEHClause for extracting resolved clause info for logging and ETW. - Remove PInvokeStubLinker::ClearCode override and manual EH label fields (m_pCleanupTryBeginLabel, m_pCleanupTryEndLabel, m_pCleanupFinallyBeginLabel, m_pCleanupFinallyEndLabel). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…t IL APIs are shaped

… stub path

This is no longer necessary as non-vararg forward P/Invokes are now truly non-shared and don't go through the ILStubCache infrastructure at all.

dotnet-policy-service · 2026-04-03T16:43:42Z

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

Copilot

Pull request overview

This PR changes CoreCLR’s handling of non-varargs P/Invokes to be implemented via transient IL rather than IL stubs, reducing per-P/Invoke stub overhead and removing related interpreter/workaround paths. It also reworks IL stub EH-clause tracking to support try/handler spans across multiple ILCodeStreams, and updates various call sites to reflect the new P/Invoke execution model.

Changes:

Switch non-varargs P/Invokes to transient-IL-backed implementations and adjust prestub/code-prep paths accordingly.
Move EH clause tracking from ILCodeStream into ILStubLinker, enabling cross-stream try/finally and try/catch constructs.
Update IL stub resolver finalization to accept configurable JIT flags and simplify EH section emission/consumption.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/vm/stubgen.h	Moves EH clause tracking ownership to `ILStubLinker`; adds `GetEHClause()` API.
src/coreclr/vm/stubgen.cpp	Updates EH tracking usage across streams; adds resolved EH-clause extraction; clears EH arrays on `ClearCode()`.
src/coreclr/vm/prestub.cpp	Routes non-varargs P/Invokes through `PrepareInitialCode` + explicit P/Invoke target resolution; varargs still use stubs.
src/coreclr/vm/method.cpp	Treats non-varargs P/Invokes as “may have native code”; explicitly excludes P/Invoke from tiered compilation eligibility; changes x86 stack arg sizing path.
src/coreclr/vm/jitinterface.cpp	Treats P/Invokes like IL/dynamic methods for `getMethodInfo` when no IL header is present.
src/coreclr/vm/ilstubresolver.h	Extends `FinalizeILStub` to take `CORJIT_FLAGS` (defaulting to `CORJIT_FLAG_IL_STUB`).
src/coreclr/vm/ilstubresolver.cpp	Uses passed-in JIT flags instead of hardcoding IL-stub flags.
src/coreclr/vm/dllimport.h	Adds APIs for transient-IL P/Invoke generation and for resolving targets; removes now-unused flag helpers.
src/coreclr/vm/dllimport.cpp	Implements transient IL generation for P/Invoke; refactors EH handling and stub finalization; updates vararg P/Invoke stub flow.
src/coreclr/inc/CrstTypes.def	Adjusts `ILStubGen` lock ordering metadata.

jkotas · 2026-04-03T17:31:03Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

AaronRobinsonMSFT · 2026-04-03T18:20:36Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

This is an important thing to check. When the transient IL logic was written we worked to make it "natural" so that from the JIT's perspective it has no clue where the IL comes from. This meant all the UnsafeAccessor functions just got inlined due to their size. Unless something has changed the inlining will happen using the same logic as any other IL JIT logic. This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

This is a long way of saying, we need to seriously think about making all of these inlinable as it could be a very distruptive change. I'm not sure which side I'd come down on now since we have LibraryImport.

jkotas · 2026-04-03T18:39:29Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

AaronRobinsonMSFT · 2026-04-03T20:27:08Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.
The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

Ugh. Why do I keep making this bad assumption. I need a brick to the head or something.

Copilot

Pull request overview

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

…-no-stub

… paths that resolve P/Invokes for the cases that they handle.

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

…time into pinvoke-no-stub

jkoritzinsky · 2026-04-21T00:07:37Z

/ba-g wasm failure is known (addressed by #127177)

…ke method (#127660) We didn't report these transitions when they were triggered from ILStubs because they already explicitly do this. Following the change of using transient IL belonging to the actual PInvoke method rather than separate ILStub methods (which should contain the same logic as the ILStub used to), we would now report the same event twice. We need therefore to also ignore the case where we are doing a PInvoke call from an actual PInvoke method. Fixes src/tests/profiler/transitions/transitions.csproj which regressed after #126509 on interpreter.

…es (#128257) ## Description #125177 implemented Swift calling convention detection in the interpreter's calli cookie generation. It inspects m_pMethodBeingCompiled->IsILStub() and walks the IL stub resolver to its StubTargetMethodDesc. This worked when forward P/Invokes were compiled as separate IL-stub DynamicMethodDescs. #126509 changed P/Invoke compilation: the PInvokeMethodDesc itself now carries the transient IL with the calli to the native target. MethodDesc::IsILStub() returns true only for DynamicMethodDesc, so IsILStub() returns false for a transient-IL P/Invoke and pContextMD stays NULL. With no context MD, CallStubGenerator::ComputeCallStub cannot enter either of its Swift detection branches. It falls through to the generic calling convention switch, leaves m_isSwiftCallConv = false, and: Never calls RewriteSignatureForSwiftLowering, so the [ref SwiftError, ref SwiftError] validation never throws InvalidProgramException. Generates a generic stub that does not preserve x21 across the native call, so SwiftError is lost on return. ## Fix In CInterpreterJitInfo::GetCookieForInterpreterCalliSig, also pass the method being compiled as pContextMD when it is a P/Invoke. The IsPInvoke branch already in ComputeCallStub then detects the Swift calling convention via PInvoke::GetCallingConvention_IgnoreErrors. Fixes#127897Fixes#127898 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkoritzinsky · 2026-04-03T16:42:29Z

This PR changes non-varargs P/Invokes to be backed by transient IL instead of by an IL stub.

This change removes 1 DynamicMethodDesc per P/Invoke and removes some interpreter workarounds we had for portable entrypoints (skipping the frame between the P/Invoke and the IL stub for perf) and Swift (ensuring we propagate back the SwiftError register reliably).

This change does not enable Tiered Compilation for P/Invoke methods. They are still considered not tierable and not eligible for ReJIT.

It also reverts #124579 as that work is no longer necessary now that regular P/Invokes are no longer using IL stubs.

…ause construction PInvokeStubLinker previously managed try-catch-finally blocks by manually creating labels, computing offsets, and constructing ILStubEHClause records. ILCodeStream already provides BeginTryBlock/EndTryBlock/BeginCatchBlock/EndCatchBlock/ BeginFinallyBlock/EndFinallyBlock APIs that handle this automatically. Changes: - Move m_buildingEHClauses and m_finishedEHClauses from ILCodeStream to ILStubLinker so EH clauses can span multiple code streams (the PInvoke stub's try-finally begins on the Marshal stream and ends on Cleanup). - Relax BeginHandler assertion to allow calling before EndTryBlock, since the finally handler may begin on a different stream than the try body. - Convert PInvokeStubLinker::Begin to use BeginTryBlock. - Convert SetCleanupNeeded to use BeginFinallyBlock instead of manually creating the cleanup finally begin label. - Convert PInvokeStubLinker::End to use EndTryBlock/EndFinallyBlock instead of manually creating try-end and finally-end labels. - Convert EmitExceptionHandler to use EndTryBlock/BeginCatchBlock/ EndCatchBlock instead of manual label management. - Replace manual EH clause construction (AppendEHClause, PopulateEHSect, GetCleanupFinallyOffsets) with ILStubLinker::GetNumEHClauses and WriteEHClauses. - Add ILStubLinker::GetEHClause for extracting resolved clause info for logging and ETW. - Remove PInvokeStubLinker::ClearCode override and manual EH label fields (m_pCleanupTryBeginLabel, m_pCleanupTryEndLabel, m_pCleanupFinallyBeginLabel, m_pCleanupFinallyEndLabel). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…t IL APIs are shaped

… stub path

This is no longer necessary as non-vararg forward P/Invokes are now truly non-shared and don't go through the ILStubCache infrastructure at all.

dotnet-policy-service · 2026-04-03T16:43:42Z

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

Copilot

Pull request overview

This PR changes CoreCLR’s handling of non-varargs P/Invokes to be implemented via transient IL rather than IL stubs, reducing per-P/Invoke stub overhead and removing related interpreter/workaround paths. It also reworks IL stub EH-clause tracking to support try/handler spans across multiple ILCodeStreams, and updates various call sites to reflect the new P/Invoke execution model.

Changes:

Switch non-varargs P/Invokes to transient-IL-backed implementations and adjust prestub/code-prep paths accordingly.
Move EH clause tracking from ILCodeStream into ILStubLinker, enabling cross-stream try/finally and try/catch constructs.
Update IL stub resolver finalization to accept configurable JIT flags and simplify EH section emission/consumption.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/vm/stubgen.h	Moves EH clause tracking ownership to `ILStubLinker`; adds `GetEHClause()` API.
src/coreclr/vm/stubgen.cpp	Updates EH tracking usage across streams; adds resolved EH-clause extraction; clears EH arrays on `ClearCode()`.
src/coreclr/vm/prestub.cpp	Routes non-varargs P/Invokes through `PrepareInitialCode` + explicit P/Invoke target resolution; varargs still use stubs.
src/coreclr/vm/method.cpp	Treats non-varargs P/Invokes as “may have native code”; explicitly excludes P/Invoke from tiered compilation eligibility; changes x86 stack arg sizing path.
src/coreclr/vm/jitinterface.cpp	Treats P/Invokes like IL/dynamic methods for `getMethodInfo` when no IL header is present.
src/coreclr/vm/ilstubresolver.h	Extends `FinalizeILStub` to take `CORJIT_FLAGS` (defaulting to `CORJIT_FLAG_IL_STUB`).
src/coreclr/vm/ilstubresolver.cpp	Uses passed-in JIT flags instead of hardcoding IL-stub flags.
src/coreclr/vm/dllimport.h	Adds APIs for transient-IL P/Invoke generation and for resolving targets; removes now-unused flag helpers.
src/coreclr/vm/dllimport.cpp	Implements transient IL generation for P/Invoke; refactors EH handling and stub finalization; updates vararg P/Invoke stub flow.
src/coreclr/inc/CrstTypes.def	Adjusts `ILStubGen` lock ordering metadata.

jkotas · 2026-04-03T17:31:03Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

AaronRobinsonMSFT · 2026-04-03T18:20:36Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

This is an important thing to check. When the transient IL logic was written we worked to make it "natural" so that from the JIT's perspective it has no clue where the IL comes from. This meant all the UnsafeAccessor functions just got inlined due to their size. Unless something has changed the inlining will happen using the same logic as any other IL JIT logic. This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

This is a long way of saying, we need to seriously think about making all of these inlinable as it could be a very distruptive change. I'm not sure which side I'd come down on now since we have LibraryImport.

jkotas · 2026-04-03T18:39:29Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

AaronRobinsonMSFT · 2026-04-03T20:27:08Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.
The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

Ugh. Why do I keep making this bad assumption. I need a brick to the head or something.

Copilot

Pull request overview

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

…-no-stub

… paths that resolve P/Invokes for the cases that they handle.

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

…time into pinvoke-no-stub

jkoritzinsky · 2026-04-21T00:07:37Z

/ba-g wasm failure is known (addressed by #127177)

…ke method (#127660) We didn't report these transitions when they were triggered from ILStubs because they already explicitly do this. Following the change of using transient IL belonging to the actual PInvoke method rather than separate ILStub methods (which should contain the same logic as the ILStub used to), we would now report the same event twice. We need therefore to also ignore the case where we are doing a PInvoke call from an actual PInvoke method. Fixes src/tests/profiler/transitions/transitions.csproj which regressed after #126509 on interpreter.

…es (#128257) ## Description #125177 implemented Swift calling convention detection in the interpreter's calli cookie generation. It inspects m_pMethodBeingCompiled->IsILStub() and walks the IL stub resolver to its StubTargetMethodDesc. This worked when forward P/Invokes were compiled as separate IL-stub DynamicMethodDescs. #126509 changed P/Invoke compilation: the PInvokeMethodDesc itself now carries the transient IL with the calli to the native target. MethodDesc::IsILStub() returns true only for DynamicMethodDesc, so IsILStub() returns false for a transient-IL P/Invoke and pContextMD stays NULL. With no context MD, CallStubGenerator::ComputeCallStub cannot enter either of its Swift detection branches. It falls through to the generic calling convention switch, leaves m_isSwiftCallConv = false, and: Never calls RewriteSignatureForSwiftLowering, so the [ref SwiftError, ref SwiftError] validation never throws InvalidProgramException. Generates a generic stub that does not preserve x21 across the native call, so SwiftError is lost on return. ## Fix In CInterpreterJitInfo::GetCookieForInterpreterCalliSig, also pass the method being compiled as pContextMD when it is a P/Invoke. The IsPInvoke branch already in ComputeCallStub then detects the Swift calling convention via PInvoke::GetCallingConvention_IgnoreErrors. Fixes#127897Fixes#127898 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkoritzinsky · 2026-04-03T16:42:29Z

This PR changes non-varargs P/Invokes to be backed by transient IL instead of by an IL stub.

This change removes 1 DynamicMethodDesc per P/Invoke and removes some interpreter workarounds we had for portable entrypoints (skipping the frame between the P/Invoke and the IL stub for perf) and Swift (ensuring we propagate back the SwiftError register reliably).

This change does not enable Tiered Compilation for P/Invoke methods. They are still considered not tierable and not eligible for ReJIT.

It also reverts #124579 as that work is no longer necessary now that regular P/Invokes are no longer using IL stubs.

…ause construction PInvokeStubLinker previously managed try-catch-finally blocks by manually creating labels, computing offsets, and constructing ILStubEHClause records. ILCodeStream already provides BeginTryBlock/EndTryBlock/BeginCatchBlock/EndCatchBlock/ BeginFinallyBlock/EndFinallyBlock APIs that handle this automatically. Changes: - Move m_buildingEHClauses and m_finishedEHClauses from ILCodeStream to ILStubLinker so EH clauses can span multiple code streams (the PInvoke stub's try-finally begins on the Marshal stream and ends on Cleanup). - Relax BeginHandler assertion to allow calling before EndTryBlock, since the finally handler may begin on a different stream than the try body. - Convert PInvokeStubLinker::Begin to use BeginTryBlock. - Convert SetCleanupNeeded to use BeginFinallyBlock instead of manually creating the cleanup finally begin label. - Convert PInvokeStubLinker::End to use EndTryBlock/EndFinallyBlock instead of manually creating try-end and finally-end labels. - Convert EmitExceptionHandler to use EndTryBlock/BeginCatchBlock/ EndCatchBlock instead of manual label management. - Replace manual EH clause construction (AppendEHClause, PopulateEHSect, GetCleanupFinallyOffsets) with ILStubLinker::GetNumEHClauses and WriteEHClauses. - Add ILStubLinker::GetEHClause for extracting resolved clause info for logging and ETW. - Remove PInvokeStubLinker::ClearCode override and manual EH label fields (m_pCleanupTryBeginLabel, m_pCleanupTryEndLabel, m_pCleanupFinallyBeginLabel, m_pCleanupFinallyEndLabel). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…t IL APIs are shaped

… stub path

This is no longer necessary as non-vararg forward P/Invokes are now truly non-shared and don't go through the ILStubCache infrastructure at all.

dotnet-policy-service · 2026-04-03T16:43:42Z

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

Copilot

Pull request overview

This PR changes CoreCLR’s handling of non-varargs P/Invokes to be implemented via transient IL rather than IL stubs, reducing per-P/Invoke stub overhead and removing related interpreter/workaround paths. It also reworks IL stub EH-clause tracking to support try/handler spans across multiple ILCodeStreams, and updates various call sites to reflect the new P/Invoke execution model.

Changes:

Switch non-varargs P/Invokes to transient-IL-backed implementations and adjust prestub/code-prep paths accordingly.
Move EH clause tracking from ILCodeStream into ILStubLinker, enabling cross-stream try/finally and try/catch constructs.
Update IL stub resolver finalization to accept configurable JIT flags and simplify EH section emission/consumption.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/vm/stubgen.h	Moves EH clause tracking ownership to `ILStubLinker`; adds `GetEHClause()` API.
src/coreclr/vm/stubgen.cpp	Updates EH tracking usage across streams; adds resolved EH-clause extraction; clears EH arrays on `ClearCode()`.
src/coreclr/vm/prestub.cpp	Routes non-varargs P/Invokes through `PrepareInitialCode` + explicit P/Invoke target resolution; varargs still use stubs.
src/coreclr/vm/method.cpp	Treats non-varargs P/Invokes as “may have native code”; explicitly excludes P/Invoke from tiered compilation eligibility; changes x86 stack arg sizing path.
src/coreclr/vm/jitinterface.cpp	Treats P/Invokes like IL/dynamic methods for `getMethodInfo` when no IL header is present.
src/coreclr/vm/ilstubresolver.h	Extends `FinalizeILStub` to take `CORJIT_FLAGS` (defaulting to `CORJIT_FLAG_IL_STUB`).
src/coreclr/vm/ilstubresolver.cpp	Uses passed-in JIT flags instead of hardcoding IL-stub flags.
src/coreclr/vm/dllimport.h	Adds APIs for transient-IL P/Invoke generation and for resolving targets; removes now-unused flag helpers.
src/coreclr/vm/dllimport.cpp	Implements transient IL generation for P/Invoke; refactors EH handling and stub finalization; updates vararg P/Invoke stub flow.
src/coreclr/inc/CrstTypes.def	Adjusts `ILStubGen` lock ordering metadata.

jkotas · 2026-04-03T17:31:03Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

AaronRobinsonMSFT · 2026-04-03T18:20:36Z

Does the change enable P/Invoke stub inlining? We may want to check the impact on JIT throughput.

This is an important thing to check. When the transient IL logic was written we worked to make it "natural" so that from the JIT's perspective it has no clue where the IL comes from. This meant all the UnsafeAccessor functions just got inlined due to their size. Unless something has changed the inlining will happen using the same logic as any other IL JIT logic. This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

This is a long way of saying, we need to seriously think about making all of these inlinable as it could be a very distruptive change. I'm not sure which side I'd come down on now since we have LibraryImport.

jkotas · 2026-04-03T18:39:29Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.

The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

AaronRobinsonMSFT · 2026-04-03T20:27:08Z

This could then result in an issue with if checks not blocking missing DLL exceptions for platform checks.
The system is setup to resolve these lazily only once they are actually called, even in the presence of inlining. This should not be a problem (modulo bugs).

Ugh. Why do I keep making this bad assumption. I need a brick to the head or something.

Copilot

Pull request overview

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

…-no-stub

… paths that resolve P/Invokes for the cases that they handle.

Copilot

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

…time into pinvoke-no-stub

jkoritzinsky · 2026-04-21T00:07:37Z

/ba-g wasm failure is known (addressed by #127177)

…ke method (#127660) We didn't report these transitions when they were triggered from ILStubs because they already explicitly do this. Following the change of using transient IL belonging to the actual PInvoke method rather than separate ILStub methods (which should contain the same logic as the ILStub used to), we would now report the same event twice. We need therefore to also ignore the case where we are doing a PInvoke call from an actual PInvoke method. Fixes src/tests/profiler/transitions/transitions.csproj which regressed after #126509 on interpreter.

…es (#128257) ## Description #125177 implemented Swift calling convention detection in the interpreter's calli cookie generation. It inspects m_pMethodBeingCompiled->IsILStub() and walks the IL stub resolver to its StubTargetMethodDesc. This worked when forward P/Invokes were compiled as separate IL-stub DynamicMethodDescs. #126509 changed P/Invoke compilation: the PInvokeMethodDesc itself now carries the transient IL with the calli to the native target. MethodDesc::IsILStub() returns true only for DynamicMethodDesc, so IsILStub() returns false for a transient-IL P/Invoke and pContextMD stays NULL. With no context MD, CallStubGenerator::ComputeCallStub cannot enter either of its Swift detection branches. It falls through to the generic calling convention switch, leaves m_isSwiftCallConv = false, and: Never calls RewriteSignatureForSwiftLowering, so the [ref SwiftError, ref SwiftError] validation never throws InvalidProgramException. Generates a generic stub that does not preserve x21 across the native call, so SwiftError is lost on return. ## Fix In CInterpreterJitInfo::GetCookieForInterpreterCalliSig, also pass the method being compiled as pContextMD when it is a P/Invoke. The IsPInvoke branch already in ComputeCallStub then detects the Swift calling convention via PInvoke::GetCallingConvention_IgnoreErrors. Fixes#127897Fixes#127898 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jkoritzinskyand others added 7 commits April 2, 2026 21:01

Use FinalizeILStub in the interop IL stub logic
1abf45e

Refactor stub generation APIs to be shaped more like how the transien…
5a476d5
…t IL APIs are shaped

Send non-vararg PInvokes down the transient IL path instead of the IL…
3426372
… stub path

Revert "Fix P/Invoke IL stub race in DoPrestub (dotnet#124579)"
cc1e281
This is no longer necessary as non-vararg forward P/Invokes are now truly non-shared and don't go through the ILStubCache infrastructure at all.

Various fixes to get the interop test tree passing locally.
4555bb3

Little cleanups
f9c441f

jkoritzinsky requested review from AaronRobinsonMSFT and Copilot April 3, 2026 16:42

github-actionsBot added the area-VM-coreclr label Apr 3, 2026

dotnet-policy-serviceBot assigned jkoritzinsky Apr 3, 2026

github-project-automationBot added this to AppModel Apr 3, 2026

Copilotstarted reviewing on behalf of jkoritzinsky April 3, 2026 16:43 View session

jkoritzinsky requested a review from jkotas April 3, 2026 16:48

CopilotAI reviewed Apr 3, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/prestub.cpp
Comment threadsrc/coreclr/vm/dllimport.cpp Outdated

jkotas reviewed Apr 3, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/dllimport.cpp Outdated

jkotas reviewed Apr 3, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/dllimport.cpp

jkotas reviewed Apr 3, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/prestub.cpp Outdated

jkotas reviewed Apr 3, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/method.cpp Outdated

jkotas reviewed Apr 3, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/method.cpp Outdated

AaronRobinsonMSFT reviewed Apr 3, 2026
View reviewed changes

PR feedback
7681f9f

Apply suggestion from@jkotas
fdbf89f

CopilotAI reviewed Apr 16, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/jitinterface.cpp
Comment threadsrc/coreclr/vm/prestub.cpp
Comment threadsrc/coreclr/vm/prestub.cpp

build-analysisBot mentioned this pull request Apr 16, 2026
linux-armel build failing with unused macro #127034
Closed

jkoritzinsky added 3 commits April 17, 2026 11:13

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto pinvoke…
736dbd9
…-no-stub

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto pinvoke…
1ad33b5
…-no-stub

Fix GC mode checks for later P/Invoke resolution
909e67f

jkotas reviewed Apr 17, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/dllimport.cpp Outdated

jkotas reviewed Apr 17, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/dllimport.cpp Outdated

Restore prestub PInvoke target resolution. Add comments to all of the…
93ef625
… paths that resolve P/Invokes for the cases that they handle.

CopilotAI review requested due to automatic review settings April 20, 2026 17:48

Copilotstarted reviewing on behalf of jkoritzinsky April 20, 2026 17:49 View session

jkotas reviewed Apr 20, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/method.cpp Outdated

Apply suggestion from@jkotas
e641566

jkotas approved these changes Apr 20, 2026
View reviewed changes

CopilotAI reviewed Apr 20, 2026
View reviewed changes

Comment threadsrc/coreclr/vm/method.cpp

jkoritzinsky added 2 commits April 20, 2026 11:33

Remove duplicate accelerator method
8acb74b

Merge branch 'pinvoke-no-stub' ofhttps://github.com/jkoritzinsky/run…
bbb9e6a
…time into pinvoke-no-stub

jkoritzinsky merged commit f9b2061 into dotnet:mainApr 21, 2026
109 of 113 checks passed

github-project-automationBot moved this to Done in AppModel Apr 21, 2026

jkoritzinsky deleted the pinvoke-no-stub branch April 21, 2026 00:08

dotnet-maestroBot mentioned this pull request Apr 21, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#6162
Merged

This was referenced Apr 21, 2026
CONTRACT VIOLATION by PInvokeImportWorker #127231
Closed
Test failure: global::GenericsTest.TestVector128C() #127209
Closed

jkoritzinsky mentioned this pull request Apr 27, 2026
Convert non-inlined unmanaged calli in CoreCLR to follow the NativeAOT model #127473
Closed

BrzVlad mentioned this pull request May 1, 2026
Don't report a interp->native transition when it is done from a pinvoke method #127660
Merged

kotlarmilos mentioned this pull request May 15, 2026
[clr-interp] Detect Swift calling convention for transient-IL P/Invokes #128257
Merged

github-actionsBot locked and limited conversation to collaborators May 21, 2026