[cDAC] Add interpreter support for stack walking and diagnostics

[max-charlamb]

Summary

Adds interpreter support to the cDAC (contract-based Data Access Component), enabling diagnostic tools to correctly walk stacks containing interpreter frames, resolve interpreter precodes, retrieve method information for interpreted methods, and surface interpreter code via the legacy SOS DAC interface.

Changes

Native Data Descriptors

• Added interpreter type descriptors to datadescriptor.inc: InterpreterRealCodeHeader, InterpreterPrecodeData, InterpByteCodeStart, InterpMethod, InterpMethodContextFrame, InterpreterFrame
• Added InterpreterFrame to frames.h explicit frame list for cDAC visibility

Execution Manager — Interpreter JIT Manager

• New ExecutionManagerCore.InterpreterJitManager handles code address lookups for interpreter code heaps
• GetCodeBlockHandle now searches interpreter code heaps when JIT heaps don't contain the address
• GetMethodDesc resolves MethodDesc from interpreter code headers

Precode Resolution (GetInterpreterCodeFromInterpreterPrecodeIfPresent)

• New API on IPrecodeStubs matching the native DAC pattern: each call site resolves interpreter precodes before passing addresses to ExecutionManager
• Passthrough semantics: returns the original address if not an interpreter precode
• NOTHROW contract via VirtualReadException catch
• Applied at 4 call sites: GetMethodDescData, CopyNativeCodeVersionToReJitData, GetTieredVersions, GetILAddressMap

Stack Walking

• FrameIterator handles InterpreterFrame — extracts MethodDesc and native code pointer from InterpMethodContextFrame
• StackWalk_1 resolves interpreter frames during enumeration and uses InterpreterVirtualUnwind instead of OS unwind when the current IP is interpreter code
• Per-arch BaseFrameHandler / AMD64FrameHandler / ARM64FrameHandler set the first-arg register to the InterpreterFrame when crossing an active InlinedCallFrame, matching the native runtime
• Cross-platform interpreter context mirroring (AMD64Context / ARM64Context / ARMContext) tracks the latest interpreter frame pointer
• Adds ARM/ARMUnwinder.cs and ARM64/ARM64Unwinder.cs so the cDAC stack walker doesn't crash when an interpreter IP has no native unwind info — outer failures return false (matching the native OOPStackUnwinder* convention) without clobbering Pc

Legacy SOS DAC Interface (SOSDacImpl)

• GetCodeHeaderData now returns CodeHeaderData for interpreter methods, populating MethodDescPtr and routing the GC-info decode by code kind
• GetILOffsetsByAddress succeeds for interpreter IPs by resolving through the interpreter code header

RuntimeTypeSystem

• MethodValidation updated to handle interpreter method descriptors (IsInterpreterStub flag, chunk validation)

Documentation

• Updated ExecutionManager.md, PrecodeStubs.md, StackWalk.md with interpreter support details

CI

• New interpreter SOS leg in eng/pipelines/runtime-diagnostics.yml exercises the new contracts under the diagnostics SOS test suite

Tests

• Unit tests: ExecutionManagerTests (interpreter JIT manager), FrameIteratorTests (interpreter frame handling), PrecodeStubsTests (interpreter precode resolution), MethodDescTests (interpreter method validation), SOSDacInterface5Tests (interpreter precode resolution via legacy interface)
• Dump tests: InterpreterStackDumpTests integration tests use a mixed JIT/interpreter stack debuggee (InterpreterStack + Trampoline) to validate interleaved frame layout, precode resolution, and thread enumeration; ISOSDacInterfaceTests validates GetCodeHeaderData for interpreter methods over a real dump

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 63 out of 64 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 62 out of 63 changed files in this pull request and generated 6 comments.

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (3)

src/native/managed/cdac/tests/DumpTests/ISOSDacInterfaceTests.cs:1

• ConditionalTheory is used but this file doesn’t import Microsoft.DotNet.XUnitExtensions, so it will fail to compile unless there’s a global using elsewhere. Add using Microsoft.DotNet.XUnitExtensions; (and optionally simplify SkipTestException usage) to make the dependency explicit.
  src/native/managed/cdac/tests/DumpTests/DumpTests.targets:1
• _DebuggeeEnvVars is already escaped earlier, but it is escaped again when passed through nested MSBuild calls. This double-escaping prevents semicolon-separated env var lists (e.g. A=B;C=D) from being restored correctly when later unescaped for Exec EnvironmentVariables (you’d end up with %3B instead of ;). Pass the value through without re-escaping (or unescape before re-escaping) so multi-variable lists remain semicolon-delimited at the final Exec.
  src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/StackWalk/Context/ARM64/ARM64Unwinder.cs:1
• Similar to the ARM change, returning false on missing unwind info risks leaving the context unchanged if the caller doesn’t propagate this failure (most of the stack walk logic expects unwind errors to surface as exceptions). To avoid stalls or partial walks, either throw an InvalidOperationException here (as before, or consistent with other unwinders) or update the unwind call sites to handle a false return deterministically.

// Licensed to the .NET Foundation under one or more agreements.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 63 out of 64 changed files in this pull request and generated 4 comments.

[noahfalk]

I think there are a few important details that are assumed by the implementation but not covered in the docs:

1. Using the native CONTEXT data structure to represent interpreter code frames. Thus far CONTEXT was used 1:1 with a physical stack frame but now we are populating it with synthetic data representing logical interpreter stack frames. There is conceptual part and also the specifics of which CONTEXT registers are used to store which elements of interpreter state.
2. Special handling for InlinedCallFrame relative to interpreter frames.
3. The anticipated enumeration ordering between InlinedCallFrame, InterpreterFrame, logical interpreted code frames, and other surrounding managed/native code frames that aren't interpreted.

I think its fine if you want to keep the current API shape right now to get things moving forward, but as we work more to support mscordbi's stackwalking and/or NativeAOT stackwalking I suspect it may be helpful to separate interpreter stackwalk and native machine stackwalking more than they currently are. For example we might have APIs approximately like this:

// A logical context for the interpreter that only stores a few fields needed to
// support unwinding interpreter frames and accessing locals
struct InterpreterContext
{
    TargetPointer IP;
    TargetPointer InterpMethodContextFrame;
    TargetPointer InterpMethodContextFrameStack;
    TargetPointer InterpreterFrame;
    bool IsFaulting;
}

class InterpreterStackwalkContract
{
    // If the native context has synthetic interpreter data in it, convert it to
    // the simplified InterpreterContext
    bool TryConvertMachineContextToInterpreterContext(
        IPlatformAgnosticContext machineContext,
        out InterpreterContext? interpreterContext);

    // Enumerate interpreter frames within a single InterpreterFrame
    IEnumerable<InterpreterContext> EnumerateInterpretedStackFrames(TargetPointer InterpreterFrame);

    // Enumerate interpreter frames within a single InterpreterFrame starting from
    // some specific initial context.
    IEnumerable<InterpreterContext> EnumerateInterpretedStackFrames(InterpreterContext startContext);
}

The basic stackwalk contract wouldn't need any special knowledge of interpreter I think, other than InterpreterFrame is one kind of Frame that might be observed. Contract consumers would be free to substitute InterpreterFrame for an enumeration of its nested frames if desired. For stackwalks where the seed CONTEXT is in interpreted code, the TryConvert API gives InterpreterContext.InterpreterFrame which can be used to recover the starting point for the base stackwalker.

[max-charlamb]

That seems reasonable. I'd like to get this in as is, then will look at follow-ups including this as well as more testing.

[noahfalk]

Nit: Is this an inlined implementation of FirstArgRegister?
It might be useful to have IPlatformAgnosticContext define methods to get/set this rather than doing platform specific overrides in every FrameHandler to specify a different register. It would also make it a little clearer what the underlying concept is guiding these register choices.