[clr-interp] Add initial CoreCLR interpreter func-eval support by matouskozak · Pull Request #126576 · dotnet/runtime

matouskozak · 2026-04-06T12:14:24Z

Description

This adds initial func-eval support for threads stopped in CoreCLR interpreter code.

Queue interpreter func-eval requests in the existing pending evals hash table (ProcessAnyPendingEvals) instead of using native-context hijacking
Execute pending evals from InterpBreakpoint after the debugger callback returns, reusing the shared dispatch path for both interpreter and exception-time evals
Skip native-only setup for interpreter evals: executable breakpoint segment allocation, SP alignment validation, and register/context updates that rely on real native frames
Rename m_evalDuringException to m_evalUsesHijack (inverted logic) to accurately describe the flag's purpose now that it covers both exception and interpreter paths
Move Init() skip logic inside DebuggerEval so callers don't need interpreter-specific conditionals
Return CORDBG_E_FUNC_EVAL_BAD_START_POINT for func-eval requests on interpreter threads not stopped at a breakpoint
Reuse the direct completion path for interpreter evals, where completion is signaled without the native breakpoint trap mechanism

Testing

Locally on iOS simulator
DiagnosticTests: Func-eval tests passing under --clrinterpreter (osx-arm64, validated locally)
- FuncEval.NestedFuncEvalTest
- FuncEval.EscapeSecondPass

FuncEval.InfiniteLoopASyncAbortTest is Windows-only and FuncEval.AssemblyLoadFuncEval is a Mono configuration.

Fixes #125959

Copilot

Pull request overview

Adds initial debugger func-eval support when the target thread is stopped in CoreCLR interpreter code, by avoiding native-context hijacking and instead running queued evals from the interpreter breakpoint path.

Changes:

Adds a pending func-eval slot to the interpreter thread context and triggers execution after the breakpoint debugger callback returns.
Extends DebugInterface/Debugger with an interpreter-specific hook to execute pending evals.
Adjusts FuncEvalSetup / DebuggerEval initialization to skip native-only setup (e.g., executable breakpoint segment allocation, SP alignment checks) for interpreter evals.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/vm/interpexec.h	Adds `InterpThreadContext::m_pPendingFuncEval` storage for interpreter-thread func-evals.
src/coreclr/vm/interpexec.cpp	Executes pending interpreter func-evals from the `INTOP_BREAKPOINT` handler using a synthetic filter context.
src/coreclr/vm/dbginterface.h	Adds `ExecutePendingInterpreterFuncEval(Thread*)` to the debug interface under `FEATURE_INTERPRETER`.
src/coreclr/debug/ee/debugger.h	Declares the `Debugger` implementation of `ExecutePendingInterpreterFuncEval`.
src/coreclr/debug/ee/debugger.cpp	Implements pending-eval execution and updates `FuncEvalSetup`/`DebuggerEval` to support interpreter eval flow.

dotnet-policy-service · 2026-04-06T16:13:56Z

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

…ogic for clarity in DebuggerEval handling

…r-funceval # Conflicts: # src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Data/Frames/DebuggerEval.cs

Copilot

Pull request overview

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

…ec.h include - Restore m_bypassAddress/m_bypassOpcode in EX_CATCH before EX_RETHROW so bypass state is not corrupted if func-eval throws - Remove unused interpexec.h include from debugger.cpp (GetInterpThreadContext is declared on Thread, not in interpexec.h) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…reterFuncEval method

Copilot

Pull request overview

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

noahfalk

Looks pretty good. I think there are a few places where a little more refactoring can simplify even further and potentially an issue about SetIP interacting with breakpoint skipping.

… in interpreter

Includes the func-eval support from dotnet#126576 plus follow-up fixes: - Skip CALL_FINALLY instructions during stepping (internal EH machinery) - Filter CallEntryPoint frames from interpreter debugger stack walks (in-process and DAC) - Add IsCallFinally() to InterpreterWalker Co-authored-by: Matous Kozak <55735845+matouskozak@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

noahfalk

LGTM!

am11 · 2026-04-28T12:13:36Z

DiagnosticTests: Func-eval tests passing under --clrinterpreter (osx-arm64, validated locally)
* FuncEval.NestedFuncEvalTest

* FuncEval.EscapeSecondPa

Are these local tests? Asking as I'd like to run them against #126809 (your and mine PR combined can be tested too; it has wasm changes in src/coreclr/vm/wasm/callhelpers-reverse.cpp and no merge-conflict is expected AFAICT).

janvorli · 2026-04-28T12:44:30Z

Are these local tests?

@am11 These are the private diagnostic tests that I was running with your PR

When debugger breakpoint is hit and then debugger resumes the execution, the context at which the breakpoint was hit can be modified. For example, one of the exception interception tests does that to continue from a different location after an exception is hit. The interpreter ignored changes in the context and resumed execution at the original breakpoint location instead of the modified context. This change fixes it by throwing the `ResumeAfterCatchException` if the context was modified. That ensures that we resume the exception correctly even if both the stack frame and the IP was changed. The `ResumeAfterCatchException` became a bit of a misnomer, but I don't want to pollute this PR by renaming the `ResumeAfterCatchException` to `ResumeException`, which would be a better name now. I'd prefer doing it in a separate PR. Follow-up to #126576 This fixes the following interpreter debugger test failure: * Exceptions.InterceptTest

…r-funceval

kotlarmilos · 2026-04-28T13:44:55Z

DiagnosticTests: Func-eval tests passing under --clrinterpreter (osx-arm64, validated locally)
* FuncEval.NestedFuncEvalTest

* FuncEval.EscapeSecondPa
Are these local tests? Asking as I'd like to run them against #126809 (your and mine PR combined can be tested too; it has wasm changes in src/coreclr/vm/wasm/callhelpers-reverse.cpp and no merge-conflict is expected AFAICT).

Merged latest main into the branch and resolved the conflicts. I verified locally that on osx-arm64 under --clrinterpreter: FuncEval.NestedFuncEvalTest, FuncEval.EscapeSecondPass, and Exceptions.InterceptTest all pass.

Copilot

Copilot's findings

Comments suppressed due to low confidence (1)

src/coreclr/debug/ee/debugger.cpp:14266

If bpInfoSegmentRX was allocated for a hijacked eval and new DebuggerEval(...) returns NULL, this returns E_OUTOFMEMORY without freeing bpInfoSegmentRX, leaking executable-heap memory. Consider keeping the heap pointer and freeing bpInfoSegmentRX on this failure path (and any other early-return paths before pDE takes ownership).

    DebuggerEval *pDE = new (interopsafe, nothrow) DebuggerEval(filterContext, pEvalInfo, bpInfoSegmentRX);

    if (pDE == NULL)
    {
        return E_OUTOFMEMORY;

Files reviewed: 9/9 changed files
Comments generated: 2

- Skip INTOP_CALL_FINALLY during stepping (internal EH machinery) - Add IsCallFinally() helper to InterpreterWalker - Filter Environment.CallEntryPoint frames from debugger stack walks (frameinfo.cpp) Follow-up to dotnet#126576. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

matouskozak added 3 commits April 2, 2026 14:59

func eval support initial

bf33f97

set filter context for func eval

f38e985

Skip allocating bpInfoSegmentRX for interpreter

5bbd2ab

matouskozak self-assigned this Apr 6, 2026

matouskozak added the area-System.Diagnostics label Apr 6, 2026

Copilot AI review requested due to automatic review settings April 6, 2026 12:14

Copilot started reviewing on behalf of matouskozak April 6, 2026 12:15 View session

clarify wording around pending func evals

ccae943

Copilot AI reviewed Apr 6, 2026

View reviewed changes

Comment thread src/coreclr/debug/ee/debugger.cpp Outdated

Comment thread src/coreclr/debug/ee/debugger.cpp Outdated

jkotas reviewed Apr 6, 2026

View reviewed changes

Comment thread src/coreclr/vm/interpexec.cpp Outdated

jkotas added area-Diagnostics-coreclr and removed area-System.Diagnostics labels Apr 6, 2026

Move FuncEval execution to InterpBreakpoint

10d728c

jkoritzinsky reviewed Apr 7, 2026

View reviewed changes

Comment thread src/coreclr/vm/interpexec.h Outdated

noahfalk reviewed Apr 9, 2026

View reviewed changes

Comment thread src/coreclr/debug/ee/debugger.cpp Outdated

Comment thread src/coreclr/debug/ee/debugger.cpp Outdated

Comment thread src/coreclr/debug/ee/debugger.cpp Outdated

Comment thread src/coreclr/debug/ee/debugger.cpp Outdated

kotlarmilos added 2 commits April 14, 2026 12:56

Merge branch 'main' into interpreter-debugger-funceval

dba74ee

Rename m_evalDuringException to m_evalUsesHijack and update related l…

03388a6

…ogic for clarity in DebuggerEval handling

Copilot AI review requested due to automatic review settings April 15, 2026 16:09

Merge remote-tracking branch 'upstream/main' into interpreter-debugge…

014eec6

…r-funceval # Conflicts: # src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Data/Frames/DebuggerEval.cs

Copilot started reviewing on behalf of kotlarmilos April 15, 2026 16:10 View session

Copilot AI reviewed Apr 15, 2026

View reviewed changes

Comment thread src/coreclr/vm/interpexec.cpp Outdated

Comment thread src/coreclr/debug/ee/debugger.cpp Outdated

kotlarmilos marked this pull request as ready for review April 15, 2026 16:20

kotlarmilos requested review from BrzVlad, janvorli and kg as code owners April 15, 2026 16:20

kotlarmilos requested review from jkoritzinsky, jkotas and noahfalk April 17, 2026 11:27

BrzVlad reviewed Apr 21, 2026

View reviewed changes

Comment thread src/coreclr/vm/interpexec.cpp Outdated

Refactor DebuggerEval handling and remove unused ExecutePendingInterp…

6ed593b

…reterFuncEval method

Copilot AI review requested due to automatic review settings April 22, 2026 09:32

Copilot started reviewing on behalf of kotlarmilos April 22, 2026 09:33 View session

Copilot AI reviewed Apr 22, 2026

View reviewed changes

Comment thread src/coreclr/vm/interpexec.cpp

noahfalk reviewed Apr 22, 2026

View reviewed changes

Refactor DebuggerEval constructor and improve bypass address handling…

2a4b5ff

… in interpreter

build-analysis Bot mentioned this pull request Apr 22, 2026

browser-wasm linux Release LibraryTests queues timing out #117974

Open

kotlarmilos requested a review from noahfalk April 27, 2026 13:24

janvorli mentioned this pull request Apr 27, 2026

Fix interpreter context after breakpoint #127480

Merged

noahfalk approved these changes Apr 28, 2026

View reviewed changes

Merge remote-tracking branch 'upstream/main' into interpreter-debugge…

881b88e

…r-funceval

Copilot AI review requested due to automatic review settings April 28, 2026 13:39

Copilot started reviewing on behalf of kotlarmilos April 28, 2026 13:39 View session

Copilot AI reviewed Apr 28, 2026

View reviewed changes

Comment thread src/coreclr/debug/ee/debugger.cpp

Comment thread src/coreclr/debug/ee/debugger.cpp

This was referenced Apr 28, 2026

[android] Got a SIGSEGV while executing native code. at System.DateTime.get_Now() #127500

Open

Android arm32 device not found (armeabi-v7a architecture unavailable) #125440

Open

Copilot AI mentioned this pull request Apr 28, 2026

[android] Enable ARM_SOFTFP for Android ARM32 to fix SIGSEGV in DateTime.Now #127527

Closed

jkoritzinsky removed their request for review April 28, 2026 20:50

kotlarmilos merged commit 25c2c30 into dotnet:main Apr 29, 2026
110 of 120 checks passed

Conversation

matouskozak commented Apr 6, 2026 • edited by kotlarmilos Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dotnet-policy-service Bot commented Apr 6, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

noahfalk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

noahfalk left a comment

Choose a reason for hiding this comment

Uh oh!

am11 commented Apr 28, 2026

Uh oh!

janvorli commented Apr 28, 2026

Uh oh!

kotlarmilos commented Apr 28, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot's findings

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

matouskozak commented Apr 6, 2026 •

edited by kotlarmilos

Loading