Fix interpreter SetIP breakpoint handling

[matouskozak]

Summary

• Preserve the destination breakpoint bypass across SetIP context mutation and consume the matching bypass before debugger notification, allowing the saved opcode to execute exactly once.
• Emit interpreter IL/native mappings for catch and filter entries whose exception object makes the IL stack non-empty, using an invalid source type rather than omitting the entry.

Validation

• macOS arm64 directly fixed Stepping.SetIPTest and Stepping.SetIPTestwithUnvaildPos (2/2).

Note

This pull request description was generated by GitHub Copilot.

[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.

[Copilot]

Pull request overview

Updates CoreCLR interpreter debugging behavior to correctly honor breakpoint bypass state across SetIP (so the destination’s saved opcode executes exactly once), and improves debugger mapping emission for catch/filter entries where the IL stack is intentionally non-empty (exception object present).

Changes:

• Preserve a destination breakpoint bypass across SetIP context mutation inside InterpBreakpoint, restoring it only when the new IP matches the saved bypass address.
• Consume a matching breakpoint bypass before notifying the debugger (pre-callback) in the INTOP_BREAKPOINT dispatch path to avoid redundant callbacks and ensure single-step execution of the saved opcode.
• Emit IL->native mapping entries for filter/catch funclet entry IL offsets even when the IL stack isn’t empty, tagging them with ICorDebugInfo::SOURCE_TYPE_INVALID instead of omitting the mapping.

Reviewed changes

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

File	Description
src/coreclr/vm/interpexec.cpp	Adjusts interpreter breakpoint/bypass flow to correctly preserve and consume bypasses around debugger SetIP and callbacks.
src/coreclr/interpreter/compiler.cpp	Emits IL->native mappings for filter/catch entrypoints with non-empty IL stack using SOURCE_TYPE_INVALID rather than skipping the entry.

[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.

[BrzVlad]

In which scenario does this happen ? Say the debugger wants to continue execution at a different ip. Then it would just set the ip to the new location and it just starts executing from there. What would be the point of setting a bypass. If the target instruction is a breakpoint, sounds like it should just execute it normally.

Maybe the debugger still wants to execute the original instruction that was trapped, before dispatching to the new location ? In that case, isn't savedBypassAddress pointing to the original breakpoint location ? Or is savedBypassAddress always pointing to the new target with the opcode from the other trapping instruction, suggesting that the debugger has enough information to always set the bypass to the right values. In which case, why are we doing this equality check, should we just set the bypass unconditionally, unifying with the code below ?

[matouskozak]

In which scenario does this happen ?

This is for the case when SetIP moves execution to a place that already has a breakpoint. After debugger resumes we would hit the breakpoint again.

If the target instruction is a breakpoint, sounds like it should just execute it normally.

I'm not sure we can because we need to exit through ThrowResumeAfterCatchException to move to the new IP, thus skipping the regular breakpoint bypass path.

Maybe the debugger still wants to execute the original instruction that was trapped, before dispatching to the new location ?

I'm not sure that's what debugger want, I would expect that if execution is changed via SetIP, we just move to the new location.

should we just set the bypass unconditionally, unifying with the code below ?

We only need the bypass in case we go to breakpoint with SetIP other case will execute normally.

[BrzVlad]

I'm not sure that's what debugger want, I would expect that if execution is changed via SetIP, we just move to the new location.

Tom's reply from below seems to suggest this is actually the case, meaning that the debugger needs to first execute the original instruction before resuming to another location. If that is the case, I would have expected unconditionally storing like this:

pThreadContext->m_bypassAddress = GetIP(&ctx);
pThreadContext->m_bypassOpcode = savedBypassOpcode;

Also, isn't savedBypassAddress always equal to the original ip ? Why would it be different ? If they are the same, then doing comparison with one above and then with the other below just adds difficulty in following the code logic.

[tommcdon]

Tom's reply from below seems to suggest this is actually the case, meaning that the debugger needs to first execute the original instruction before resuming to another location.

When the debugger stops at an instruction because it hit a breakpoint, the instruction at the current IP has not executed yet.

If SetIP changes the IP, we do not execute the original instruction first because execution moves to the destination.

Also, isn't savedBypassAddress always equal to the original ip ?

It is the original IP on normal continue. However, if SetIP targets another breakpoint, it is the destination IP. If the destination is not patched, if the destination is not patched, it will be NULL.

Why would it be different ?

savedBypassAddress will point to the new destination breakpoint because, once we have continued, we have already looked up the patch at the new IP.

[BrzVlad]

I believe things are starting to make sense now. Some conclusions that need validation

• the key expected flow logic is that, if we resume to an opcode that has a breakpoint, we don't trigger the breakpoint again, we just execute the opcode at that address and implicitly continue execution. This is what was counter intuitive to me.
• within FirstChanceNativeException, the debugger sets both the IP, as well as the bypass info on the interp thread context for the destination IP. This destination IP can be either the ip of the breaking instruction or some other IP.
• given ProcessAnyPendingEvals executes other managed code, the original bypass state gets lost so we have to save it. ProcessAnyPendingEvals should be able to change the ip again. Does it also set the bypass for the new destination ? From what I search through the code I suspect it might not
• what happens if ProcessAnyPendingEvals will ask to resume to an ip that is different from original savedBypassAddress. It will not add the bypass if that location contains a breakpoint. Does this mean we don't support ip changes done from the eval execution ?

[janvorli]

It is not clear to me why we want to execute the bypass byte code. Do we do that for JITted code too? I would expect that in native code, if I set a breakpoint at say a division instruction, we would not execute that instruction until we resume after breakpoint. Why would the interpreter be different?

[matouskozak]

This bypass dispatch was intended for a case where SetIP redirects to a location with another breakpoint. In that case, when we resume execution via ThrowResumeAfterCatchException, we would hit the breakpoint at SetIP location, bypassing it here we can dispatch to the underlying opcode instead of hitting another breakpoint.

I thought this would be safe, as I don't expect we would have more than one bypass set at given ip and so if there is a bypass already set when we hit INTOP_BREAKPOINT it must have come from SetIP.

[tommcdon]

Do we do that for JITted code too?

Yes we do have the same patch-skip concept for JITted code, implemented at the native instruction level.

I would expect that in native code, if I set a breakpoint at say a division instruction, we would not execute that instruction until we resume after breakpoint. Why would the interpreter be different?

Correct. We do not execute the patched instruction when stopping at the breakpoint. The bypass is installed when the debugger resumes execution and executes the saved original instruction once. With SetIP, if the destination contains a breakpoint patch, the interpreter needs the same behavior; otherwise, it immediately reports that destination breakpoint instead of executing the requested instruction.