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

[matouskozak]

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: FuncEval (NestedFuncEval, EscapeSecondPass), Breakpoints, Stepping, all pass with --clrinterpreter

Future Work

• JMC stepping and CallEntryPoint frame filtering for interpreter
• Exception interception support for interpreter

#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]

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

[Copilot]

Pull request overview

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

[BrzVlad]

Is this code ever reached ? I would imagine func evals should catch all exceptions and never crash the app.

[janvorli]

Looking at the code for funceval, while all exceptions from the funceval invocation are caught in FuncEvalHijackRealWorker, there are methods called after the funceval itself that are marked as THROWS, e.g. the Debugger::FuncEvalComplete. I am not sure what are all the exception kinds that can stem from there, but one of them is OOM.

[BrzVlad]

I'm wondering if it makes more sense to assert in checked build here rather than rethrowing, otherwise silently ignore the error. Seems wrong to have a function called from the debugger crash the app.

[janvorli]

It doesn't sound right to ignore OOM exceptions. Those would very likely kick in a bit later again anyways.