[clr-ios] Fix JMC stepping and CallEntryPoint frame filtering

[kotlarmilos]

Description

Fix JMC stepping and debugger stack walk filtering for interpreter frames: skip INTOP_CALL_FINALLY during stepping (internal EH machinery), filter CallEntryPoint from debugger stack walks in both the in-process and DAC frame iterators, add a pre-callback bypass check to avoid redundant debugger notifications, and improve bypass save/restore around func-eval execution.

Follow-up to #126576

This fixes the following interpreter debugger test failures:

• JMC.jmcClasses
• JMC.jmcFunceval
• JMC.jmcChange
• JMC.jmcDelegates
• JMC.jmcModules

[Copilot]

Pull request overview

Fixes interpreter-specific debugging behaviors around JMC stepping, stack walking, and func-eval/breakpoint handling so that interpreter behavior matches JIT expectations and avoids redundant debugger callbacks.

Changes:

• Add interpreter-aware stepping logic to skip internal INTOP_CALL_FINALLY boundaries during JMC stepping.
• Filter Environment.CallEntryPoint from debugger stack walks (in-proc and DAC) to match JIT visibility behavior.
• Refine interpreter breakpoint + func-eval handling (pre-callback bypass checks, bypass save/restore around func-eval, and allow SetIP to change interpreter IP).

Reviewed changes

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

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Data/Frames/DebuggerEval.cs	Rename contract flag to EvalUsesHijack for interpreting func-eval behavior in stack walking.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/StackWalk/FrameHandling/BaseFrameHandler.cs	Use EvalUsesHijack to decide whether to update context from func-eval frame.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/StackWalk/FrameHandling/X86FrameHandler.cs	Same as BaseFrameHandler, with x86-specific context copying.
src/coreclr/vm/interpexec.cpp	Interpreter breakpoint handler updates (pre/post bypass checks, pending interpreter func-eval execution, SetIP support).
src/coreclr/vm/dbginterface.h	Add ExecutePendingInterpreterFuncEval hook for interpreter breakpoint handler.
src/coreclr/vm/datadescriptor/datadescriptor.inc	CDAC descriptor rename: EvalDuringException → EvalUsesHijack.
src/coreclr/debug/ee/interpreterwalker.h	Add InterpreterWalker::IsCallFinally() helper.
src/coreclr/debug/ee/interpreterwalker.cpp	Implement IsCallFinally().
src/coreclr/debug/ee/funceval.cpp	Replace m_evalDuringException checks with m_evalUsesHijack.
src/coreclr/debug/ee/frameinfo.cpp	Filter Environment.CallEntryPoint in debugger stack walk for interpreter mode.
src/coreclr/debug/ee/debugger.h	Rename state flag and skip bp-segment executability check when not using hijack.
src/coreclr/debug/ee/debugger.cpp	Interpreter-aware func-eval setup (skip executable heap allocation for interpreter) and expose ExecutePendingInterpreterFuncEval.
src/coreclr/debug/ee/controller.cpp	Stepper logic to skip INTOP_CALL_FINALLY boundaries when stepping interpreted code.
src/coreclr/debug/daccess/dacdbiimplstackwalk.cpp	DAC stack walk filtering for Environment.CallEntryPoint under interpreter.

Comments suppressed due to low confidence (1)

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

• In the interpreter func-eval path, bpInfoSegmentRX is NULL, but DebuggerEval::Init() is called before m_evalUsesHijack is flipped to false. Because the ctor currently initializes m_evalUsesHijack to !fInException (true for non-exception interpreter evals), Init() will dereference m_bpInfoSegment and can crash. Set m_evalUsesHijack correctly before calling Init (e.g., initialize it in the ctor from both fInException and whether bpInfoSegmentRX is non-null, or delay Init() until after the interpreter-specific flag update), and consider adding an assert/guard in Init to ensure m_bpInfoSegment is non-null when m_evalUsesHijack is true.

    // Create a DebuggerEval to hold info about this eval while its in progress. Constructor copies the thread's
    // CONTEXT.
    DebuggerEval *pDE = new (interopsafe, nothrow) DebuggerEval(filterContext, pEvalInfo, fInException, bpInfoSegmentRX);

    if (pDE == NULL)
    {
        return E_OUTOFMEMORY;
    }
    else if (!pDE->Init())
    {
        // We fail to change the m_breakpointInstruction field to PAGE_EXECUTE_READWRITE permission.
        return E_FAIL;
    }

[dotnet-policy-service]

Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[steveisok]

@kotlarmilos would it make sense to drop the #ifdef FEATURE_INTERPRETER guards around
the two CallEntryPoint filter hunks (in frameinfo.cpp::DebuggerWalkStackProc
and dacdbiimplstackwalk.cpp::UnwindStackWalkFrame) so the filter applies on
JIT targets too?

The comment "to match JIT behavior" suggests the JIT is expected to hide
CallEntryPoint — but in practice [UnmanagedCallersOnly] disables inlining
(UCO methods must have a real, callable entry point), so the frame is visible
to ICorDebug on JIT targets as well. We're seeing it in
dotnet/dotnet-diagnostictests on linux-x64, win-x64, win-x86, and osx-arm64
JIT legs in build
2955987,
adding one frame below Program.Main.