Skip to content

[clr-interp] Add initial CoreCLR interpreter func-eval support#126576

Draft
matouskozak wants to merge 4 commits intodotnet:mainfrom
matouskozak:interpreter-debugger-funceval
Draft

[clr-interp] Add initial CoreCLR interpreter func-eval support#126576
matouskozak wants to merge 4 commits intodotnet:mainfrom
matouskozak:interpreter-debugger-funceval

Conversation

@matouskozak
Copy link
Copy Markdown
Member

@matouskozak matouskozak commented Apr 6, 2026

Description

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

  • execute pending evals from the interpreter breakpoint path after the debugger callback returns
  • queue interpreter func-eval requests on the interpreter thread context instead of using native-context hijacking
  • skip native-only setup for interpreter evals, including executable breakpoint segment allocation, SP alignment validation, and register/context updates that rely on real native frames
  • reuse the direct completion path for interpreter evals, where completion is signaled without the native breakpoint trap mechanism

Testing:

  • Locally on iOS simulator
  • DiagnosticTest TBD

Future Work

  • Func evaluation on exceptions

#125959

@matouskozak matouskozak self-assigned this Apr 6, 2026
Copilot AI review requested due to automatic review settings April 6, 2026 12:14
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

// FuncEvalHijackWorker needs it to identify the thread as stopped in managed
// code and at a GC-safe point. Set a synthetic filter context here so that
// nested/subsequent func evals can pass the safety checks in FuncEvalSetup.
if (pThreadContext->m_pPendingFuncEval != NULL && g_pDebugInterface != NULL)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be done inside InterpBreakpoint?

CONTEXT is a very large structure. We do not want to add it to the main interpreter executor loop native frame. It would likely regress performance of the interpreter executor loop.

@dotnet-policy-service
Copy link
Copy Markdown
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants