[cDAC] Map entry point to code start in GetMethodVarInfo; make ReJIT optional in IsVersionable by lewing · Pull Request #135430 · dotnet/runtime

lewing · 2026-10-08T16:00:19Z

Two IDebugInfo.GetMethodVarInfo fixes for targets that use portable entry points, such as CoreCLR WebAssembly.

`GetMethodVarInfo` code offset

codeOffset was computed relative to ICodeVersions.GetNativeCode, which is the method's entry point. On portable-entrypoint targets that is not the code start, so the offset was wrong. The entry point is now mapped with IExecutionManager.GetDiagnosticCodeStartFromEntryPoint (#134827), the cDAC mirror of the runtime's GetDiagnosticCodeStartFromEntryPoint. It returns:

the interpreter bytecode for an interpreted method;
the R2R virtual IP for a portable entry point;
otherwise the address unchanged.

Native ClrDataAccess::GetMethodVarInfo maps only interpreter entry points (GetInterpreterCodeFromEntryPointIfPresent). The native DAC does not support wasm, so the R2R portable-entrypoint case has no native DAC behavior to compare against.

`IsVersionable` without the ReJIT contract

GetMethodVarInfo → GetNativeCodeVersionForIP → IsVersionable required the ReJIT contract. The runtime advertises that contract only under PROFILING_SUPPORTED, which is off on wasm, so GetMethodVarInfo threw ContractMissingException there. Wasm also lacks FEATURE_REJIT, so native IsEligibleForReJIT is false. A missing contract is now treated as not ReJIT-eligible, using TryGetContract.

An alternative is to advertise ReJIT on wasm, with IsEnabled() returning false; I'm happy to switch if reviewers prefer that. Separately, CoreCLRContracts.ValidateForDataAccess still requires IReJIT, so on wasm the official DAC entry point would fail validation. That is not changed here and needs its own follow-up.

Validation

./build.sh -s tools.cdactests -test: passed (Unit tests 3293/3293, DataGenerator 46/46, Usage 4/4).
generate-docs.ps1 -Check: up to date.
New tests:
- GetMethodVarInfo_CodeOffsetIsRelativeToDiagnosticCodeStart (theory: identity mapping, and an entry point mapped to a different code start).
- IsVersionable_ReJITContractOptional (theory: no ReJIT contract, ReJIT disabled, ReJIT enabled).
GetDebugInfo_R2R_NoDebugInfoSection_ReturnsNull now registers FeatureFlags and PrecodeStubs, which the mapping requires.
Mutation checks, each confirmed applied by diff and restored afterwards:
- Revert to cv.GetNativeCode(ncvh) → GetMethodVarInfo_CodeOffset…(0x400000→0x80010100) fails with Assert.Equal.
- Revert to _target.Contracts.ReJIT.IsEnabled() → IsVersionable_ReJITContractOptional(advertiseReJIT: False) fails with ContractMissingException.
I also checked against a live CoreCLR browser-wasm target with R2R. Entry point 0x41ADC1C maps to diagnostic start 0x800104B3, and GetMethodVarInfo returns offset 0x2. That is the same result as a wasm-only offset computation used in an earlier prototype. That target used a producer-side branch with variable debug info ([wasm] Preserve R2R variable debug information #133086); there is no automated test for this case.

Note

This PR description was generated with GitHub Copilot.

…onal in IsVersionable GetMethodVarInfo computed codeOffset relative to the native-code entry point. With portable entry points the entry point is not the code start, so map it with IExecutionManager.GetDiagnosticCodeStartFromEntryPoint (the cDAC mirror of the runtime's GetDiagnosticCodeStartFromEntryPoint). IsVersionable required the ReJIT contract, which is only advertised with profiling support. Without it, native IsEligibleForReJIT is false, so treat a missing ReJIT contract as not ReJIT-eligible. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

azure-pipelines · 2026-10-08T16:01:24Z

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 · 2026-10-08T16:01:37Z

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

rcj1 · 2026-10-08T17:29:46Z

Entry point 0x41ADC1C maps to diagnostic start 0x800104B3, and GetMethodVarInfo returns offset 0x2.

Are you able to select the correct debug info with offset 0x2 - for example, as this API is being used here?

runtime/src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/ClrDataFrame.cs

Lines 927 to 932 in bcb511a

    
           { 
        
               if (varInfo.StartOffset <= codeOffset && 
        
                   varInfo.EndOffset >= codeOffset && 
        
                   varInfo.VarNumber == varNumber) 
        
               { 
        
                   IPlatformAgnosticContext platformContext = IPlatformAgnosticContext.GetContextForPlatform(target);

…onal in IsVersionable Cherry-pick of dotnet#135430. GetMethodVarInfo maps the native code version's entry point with IExecutionManager.GetDiagnosticCodeStartFromEntryPoint, and IsVersionable treats a missing ReJIT contract as not ReJIT-eligible. This replaces the wasm-only GetMethodCodeOffset branch (and its unit test): WASM now takes the shared path. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

lewing · 2026-10-09T08:28:32Z

Are you able to select the correct debug info with offset 0x2 - for example, as this API is being used here?

Not in general on WASM. The 0x2 is in the R2R virtual-IP space: WASM virtual IPs are synthetic per-call/try counters assigned by fgWasmVirtualIP, and the GC info uses the same space (codeSize = 2 * maxVirtualIP). The variable ranges, on the other hand, are recorded at JIT emitter offsets (m_StartEmitLocation.CodeOffset), so StartOffset <= codeOffset <= EndOffset in FindAndResolveVarLocation compares two different offset spaces.

It works today only because unoptimized WASM scopes are method-wide (#133086 opens them in the first emitted block), so any offset inside the method selects them. A variable whose location changes mid-method, for example a parameter homed from its wasm local in the prolog, can select the wrong record. Fixing that needs either virtual-IP-space ranges from the producer or a virtual-IP → native-offset map. It's listed as a limitation on #133890.

This PR doesn't change that: on WASM, the shared path now returns the same offset the wasm-specific path in #133890 did, and #133890 now uses this path instead.

Note

This comment was generated with GitHub Copilot.

rcj1 · 2026-10-09T13:49:52Z

Are you able to select the correct debug info with offset 0x2 - for example, as this API is being used here?

Not in general on WASM. The 0x2 is in the R2R virtual-IP space: WASM virtual IPs are synthetic per-call/try counters assigned by fgWasmVirtualIP, and the GC info uses the same space (codeSize = 2 * maxVirtualIP). The variable ranges, on the other hand, are recorded at JIT emitter offsets (m_StartEmitLocation.CodeOffset), so StartOffset <= codeOffset <= EndOffset in FindAndResolveVarLocation compares two different offset spaces.

It works today only because unoptimized WASM scopes are method-wide (#133086 opens them in the first emitted block), so any offset inside the method selects them. A variable whose location changes mid-method, for example a parameter homed from its wasm local in the prolog, can select the wrong record. Fixing that needs either virtual-IP-space ranges from the producer or a virtual-IP → native-offset map. It's listed as a limitation on #133890.

This PR doesn't change that: on WASM, the shared path now returns the same offset the wasm-specific path in #133890 did, and #133890 now uses this path instead.

Note

This comment was generated with GitHub Copilot.

Makes sense, I’ll approve this for now then.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

lewing · 2026-10-12T13:12:59Z

@rcj1 I had to commit again to merge main

lewing · 2026-10-13T10:08:10Z

/ba-g failure is not related

…rames (#136362) 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 #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`. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

github-actions Bot added the area-Diagnostics-coreclr label Oct 8, 2026

dotnet-policy-service Bot assigned lewing Oct 8, 2026

lewing mentioned this pull request Oct 9, 2026

[cDAC][wasm] Decode R2R variable locations and expose function identity #133890

Open

rcj1 approved these changes Oct 9, 2026

View reviewed changes

Merge origin/main into lewing-cdac-varinfo-entrypoint

9360c26

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

lewing marked this pull request as ready for review October 12, 2026 10:11

build-analysis Bot mentioned this pull request Oct 12, 2026

[ci-scan] Test failure: GCRefStress_AllVerificationsPass misses a Windows x86 PrestubMethodFrame root #135086

Closed

rcj1 approved these changes Oct 12, 2026

View reviewed changes

lewing enabled auto-merge (squash) October 13, 2026 09:15

lewing merged commit 9b17eb8 into dotnet:main Oct 13, 2026
83 of 85 checks passed

dotnet-maestro Bot mentioned this pull request Oct 14, 2026

[main] Source code updates from dotnet/runtime dotnet/dotnet#10153

Merged

dotnet-milestone-bot Bot added this to the 12.0-preview1 milestone Oct 14, 2026

steveisok mentioned this pull request Oct 23, 2026

[cDAC] Fix native code version lookup and caller SP for interpreted frames #136362

Merged

Navigation Menu

Repository navigation

[cDAC] Map entry point to code start in GetMethodVarInfo; make ReJIT optional in IsVersionable - #135430

[cDAC] Map entry point to code start in GetMethodVarInfo; make ReJIT optional in IsVersionable#135430
lewing merged 2 commits into
dotnet:mainfrom
lewing:lewing-cdac-varinfo-entrypoint

lewing commented Oct 8, 2026 •

edited

Loading

Uh oh!

azure-pipelines Bot commented Oct 8, 2026

Uh oh!

dotnet-policy-service Bot commented Oct 8, 2026

Uh oh!

rcj1 commented Oct 8, 2026 •

edited

Loading

Uh oh!

lewing commented Oct 9, 2026

Uh oh!

rcj1 commented Oct 9, 2026

Uh oh!

lewing commented Oct 12, 2026

Uh oh!

lewing commented Oct 13, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

lewing commented Oct 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GetMethodVarInfo code offset

IsVersionable without the ReJIT contract

Validation

Uh oh!

azure-pipelines Bot commented Oct 8, 2026

Uh oh!

dotnet-policy-service Bot commented Oct 8, 2026

Uh oh!

rcj1 commented Oct 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lewing commented Oct 9, 2026

Uh oh!

rcj1 commented Oct 9, 2026

Uh oh!

lewing commented Oct 12, 2026

Uh oh!

lewing commented Oct 13, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

lewing commented Oct 8, 2026 •

edited

Loading

`GetMethodVarInfo` code offset

`IsVersionable` without the ReJIT contract

rcj1 commented Oct 8, 2026 •

edited

Loading