fix invalid IL in profiler stub helper

[davmason]

Fixes #45411

Profilers can set COR_PRF_MONITOR_CODE_TRANSITIONS to be notified when a PInvoke, COM call, etc causes execution to leave or enter the runtime. It works by injecting some additional IL in the transition stubs. The injected IL was loading integer constants of 0 for the pThis argument of StubHelpers.ProfilerBeginTransitionCallback(IntPtr pSecretParam, IntPtr pThread, object pThis). This worked fine but was technically illegal according to the spec. The first two arguments do want an integer constant for the IntPtr, but the third is a reference and needs to be a reference type.

#43386 added checks that would cause the JIT to throw an InvalidProgramException if illegal implicit casts were detected, causing some profiler tests to fail.

[ghost]

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

Issue Details

---

Fixes #45411

Profilers can set COR_PRF_MONITOR_CODE_TRANSITIONS to be notified when a PInvoke, COM call, etc causes execution to leave or enter the runtime. It works by injecting some additional IL in the transition stubs. The injected IL was loading integer constants of 0 for the pThis argument of StubHelpers.ProfilerBeginTransitionCallback(IntPtr pSecretParam, IntPtr pThread, object pThis). This worked fine but was technically illegal according to the spec. The first two arguments do want an integer constant for the IntPtr, but the third is a reference and needs to be a reference type.

#44506 added checks that would cause the JIT to throw an InvalidProgramException if illegal implicit casts were detected, causing some profiler tests to fail.

Author:	davmason
Assignees:	davmason
Labels:	area-Diagnostics-coreclr
Milestone:	-

[davmason]

@sandreenko while investigating and testing this I found out that the checks you added in #43386 are ignored if the call ends up being inlined. That seems counter intuitive to me, I am not sure if you know about that already so I thought I would point it out.

[sandreenko]

@sandreenko while investigating and testing this I found out that the checks you added in #43386 are ignored if the call ends up being inlined. That seems counter intuitive to me, I am not sure if you know about that already so I thought I would point it out.

I am not sure what you mean, do we try to inline a method that does not pass impCheckImplicitArgumentCoercion` checks? Could you give me an example?

I can imagine a situation where we have 3 calls: call1->call2(arg a)->call3(arg b) and when we check call2(arg a) impCheckImplicitArgumentCoercion return true, when we check call3(arg b) inside call2 it returns true, but when we inline call3 into call2 it returns false somehow but then I expect this assert in impInlineInitVars to fail

runtime/src/coreclr/src/jit/importer.cpp

Line 19537 in cd5619b

assert(impCheckImplicitArgumentCoercion(sigType, inlArgNode->gtType));

[davmason]

@sandreenko nevermind, I reran my tests and I see them failing even with inlined methods. Last night when I was testing I must have been changing multiple things at once,

[sdmaclea]

LGTM, but I don't know this code area well.