[steveisok]

Independent of #136361 in code, but end-to-end testing on iOS needs #136361, otherwise in-app debugging never attaches.

Summary

With the cDAC as the in-app IDacDbiInterface on CoreCLR iOS, where Debug
app code runs on the interpreter, the debugger never reported
Debugger.Break. Two cDAC divergences from the native DAC cause this, one per
commit.

1. Map entry point to code start when finding a native code version

CodeVersions_1.GetSpecificNativeCodeVersion compared the MethodDesc native
code slot with the code-block start. For interpreted methods the slot holds an
InterpreterPrecode and the code block starts at the bytecode, so the two
never matched.

• GetNativeCodeVersionForIP returned an invalid handle.
• DebugInfo_1.GetMethodVarInfo threw "No NativeCodeVersion found for native
  code …" (0x80131509).
• GetNativeCodeSequencePointsAndVarInfo failed, the DBI abandoned the frame,
  and the stop was dropped.

The fix maps the default and explicit versions' native code through
IExecutionManager.GetDiagnosticCodeStartFromEntryPoint before comparing.
That's the helper #135430 added for GetMethodVarInfo; it covers interpreter
precodes and portable entry points. It matches the native DAC's
GetInterpreterCodeFromEntryPointIfPresent(NativeCodeVersion::GetNativeCode())
pattern. #135430 alone isn't enough, because the throw happens before its
offset mapping.

Tests and docs:

• CodeVersionsTests.GetNativeCodeVersion_Interpreted_MapsPrecodeToBytecode
  (4 architectures).
• The mock AddCodeBlock gets a default identity
  GetDiagnosticCodeStartFromEntryPoint.
• CodeVersions.md pseudo-code updated.

2. Compute caller SP for interpreted frames like the native code manager

StackWalk_1.CallerStackPointer backs GetRuntimeFramePointer on
caller-SP architectures such as ARM64, and GetFuncletRootId
(fpParentOrSelf). It always ran the OS unwinder, which has no unwind info for
bytecode, so fp/fpParentOrSelf came back as the frame's own SP.

For interpreter code it now uses the new
FrameHelpers.InterpreterCallerStackPointer, which returns:

• the parent InterpMethodContextFrame, including the zeroed root frame
  (ip == NULL) of an interpreter activation, or
• the owning InterpreterFrame when there is no parent.

This is the SP that native VirtualUnwindInterpreterCallFrame (eetwain.cpp)
gives the caller context. The walker's own unwind path (Next) is unchanged.

Tests and docs:

• StackWalkTests.CallerStackPointer_InterpretedFrame_IsParentInterpMethodContextFrame
  and StackWalkTests.CallerStackPointer_InterpretedFrameWithRootParent_IsRootFrameAddress.
• StackWalk.md updated.

Validation

• Unit tests (Microsoft.Diagnostics.DataContractReader.Tests):
  • 3,406/3,406 pass after commit 1, and 3,408/3,408 after commit 2.
  • Each new test fails without its own commit's product change and passes
    with it.
  • Microsoft.Diagnostics.DataContractReader.Usage.Tests: 4/4 after each
    commit.
• iOS Simulator (iossimulator-arm64, interpreted Debug app, VS Code .NET MAUI
  F5 flow, DOTNET_ENABLE_CDAC=1, with Fix TryGetSymbol on iOS, tvOS and Mac Catalyst #136361 applied):
  • Debugger.Break stops, and stepping, Locals and caller inspection all
    work.
  • A diagnosis-only trace compared each cDAC result with the legacy DAC for
    the same calls during the whole workflow:
    • GetNativeCodeSequencePointsAndVarInfo: 8/8 calls match in HRESULT,
      variable count and sequence-point count;
    • GetStackWalkCurrentFrameInfo: 0 mismatches in 975 compared frame
      fields (including fp, fpParentOrSelf, method token and
      MethodDesc, native start and offset, and context) across 288 frames,
      covering every frame token in the session.
  • Without these commits, the same scenario never reports Debugger.Break.

[azure-pipelines]

Azure Pipelines:
Successfully started running 5 pipeline(s).
11 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: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[steveisok]

/ba-g SOS test failures will be fixed by dotnet/diagnostics#6143