Adding GetCodeHeaderData cDAC API #119609

rcj1 · 2025-09-12T00:18:40Z

Adding GetCodeHeaderData cDAC API
Implementing unwind data size on platforms other than x86 in helper class
required additions to hot/cold lookup helpers

Copilot

Pull Request Overview

This PR adds the GetCodeHeaderData cDAC API implementation, which retrieves code header information for a given instruction pointer. The implementation includes hot/cold region detection and unwind data size calculations across different architectures.

Replaces the legacy interface implementation with a proper cDAC contract-based implementation
Adds support for calculating unwind data sizes on all supported architectures (X64, ARM, ARM64, LoongArch64, RiscV64)
Implements hot/cold method region detection and size calculation through execution manager extensions

Reviewed Changes

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

Show a summary per file

File	Description
SOSDacImpl.cs	Implements GetCodeHeaderData with proper error handling and debug validation
ISOSDacInterface.cs	Adds strongly-typed DacpCodeHeaderData struct and JITTypes enum
UnwindInfo.cs	Extends UnwindInfo data class to support unwind codes on non-x86 platforms
UnwindDataSize.cs	New helper class for calculating unwind data sizes across all architectures
HotColdLookup.cs	Adds method to retrieve hot/cold region boundaries
ExecutionManager files	Adds new APIs for method region info, JIT type detection, and non-virtual entry lookup
datadescriptor.inc	Updates UnwindInfo and adds UnwindCode type definitions
ExecutionManager.md	Documents the new ExecutionManager APIs and their implementation details

...ractReader.Contracts/Contracts/ExecutionManager/ExecutionManagerCore.ReadyToRunJitManager.cs

dotnet-policy-service · 2025-09-12T00:23:21Z

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

rcj1 · 2025-09-12T00:27:48Z

Separate PR idea: more detailed hot/cold map documentation? @elinor-fung

rcj1 · 2025-09-12T00:55:55Z

docs/design/datacontracts/ExecutionManager.md

+    if (/* no corresponding range section */)
+        return null;
+
+    if (/* range flags indicate RangeList */)


@elinor-fung @jkotas any way to simplify this, can these checks be absorbed into GetMethodDescFromStubAddress?

In any case I think we need the capability to turn this additional search on and off because SOS uses the failure case of GetMethodDescPtrFromIP to indicate some things about the type of method we are looking at. Here is an (undocumented) example but there are more:

https://github.com/dotnet/diagnostics/blob/23d4e5f6eadc48f12ce8cda6174e3a8b85e3c638/src/SOS/Strike/strike.cpp#L9262

I think we need to have two different non-legacy methods:

API that takes IP that points to the start or into middle of an actual method code, and maps it MethodDesc, hot/cold region sizes, GCInfo, etc. GetMethodRegionInfo looks close.

API that take method entrypoint (that may not actually be a pointer to the actual code in some configuration - see my other comment), and maps it to MethodDesc. Equivalent of runtime's NonVirtualEntry2MethodDesc.

The legacy methods can be hopefully implemented using these two APIs in a compatible-enough way.

max-charlamb

It looks like our method for computing method size (summing RUNTIME_FUNCTIONs lengths) is different than the runtimes (reading the GCInfo). Will this always yield the same result?

max-charlamb · 2025-09-12T01:34:55Z

....Diagnostics.DataContractReader.Contracts/Contracts/ExecutionManager/ExecutionManagerCore.cs

+    private enum JITTypes
+    {
+        TYPE_UNKNOWN = 0,
+        TYPE_JIT = 1,
+        TYPE_PJIT = 2,
+        TYPE_INTERPRETER = 3
+    };


We can make this public in IExecutionManager and change the return type of GetJitType to JitType.

....Diagnostics.DataContractReader.Contracts/Contracts/ExecutionManager/ExecutionManagerCore.cs

src/coreclr/vm/datadescriptor/datadescriptor.inc

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Data/UnwindInfo.cs

...iagnostics.DataContractReader.Contracts/Contracts/ExecutionManager/Helpers/UnwindDataSize.cs

max-charlamb · 2025-09-12T03:07:45Z

src/native/managed/cdac/mscordaccore_universal/Legacy/SOSDacImpl.cs

+            if (codeBlockHandle == null)
+            {
+                TargetPointer methodDesc = executionManager.NonVirtualEntry2MethodDesc(targetCodePointer);
+                if (methodDesc == TargetPointer.Null)
+                    throw new ArgumentException();
+                data->MethodDescPtr = methodDesc.ToClrDataAddress(_target);
+                data->JITType = JITTypes.TYPE_UNKNOWN;
+                data->GCInfo = 0;
+                data->MethodStart = 0;
+                data->MethodSize = 0;
+                data->ColdRegionStart = 0;
+            }


Is there a reason that we don't set HotRegionSize or ColdRegionSize here? I see that the DAC doesn't, but that was probably an oversight and could get updated for consistency.

It is how this API communicates that the address is a stub (most likely a precode these days) and not an actual code.

HotRegionSize/ColdRegionSize may not be even readily available for some of the stubs.

...ed/cdac/Microsoft.Diagnostics.DataContractReader.Abstractions/Contracts/IExecutionManager.cs

docs/design/datacontracts/ExecutionManager.md

jkotas · 2025-09-13T00:24:43Z

It looks like our method for computing method size (summing RUNTIME_FUNCTIONs lengths) is different than the runtimes (reading the GCInfo). Will this always yield the same result?

I do not think these will yield the same result. There can be padding or data that's not included in the unwind infos in between the unwind infos or at the end.

rcj1 · 2025-09-13T13:57:39Z

It looks like our method for computing method size (summing RUNTIME_FUNCTIONs lengths) is different than the runtimes (reading the GCInfo). Will this always yield the same result?

I do not think these will yield the same result. There can be padding or data that's not included in the unwind infos in between the unwind infos or at the end.

Yes I now notice the results being different in CI with the cDAC giving significantly higher method lengths.

rcj1 · 2025-09-15T20:03:27Z

Waiting for GetStackReferences to merge (this should include GCInfo decoding stuff)

dotnet-policy-service · 2025-10-15T20:31:14Z

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

rcj1 added 2 commits September 11, 2025 17:11

adding GetCodeHeaderData cDAC API

2f904c3

fix

db6229a

rcj1 requested review from Copilot and elinor-fung September 12, 2025 00:18

github-actions bot added the area-Diagnostics-coreclr label Sep 12, 2025

rcj1 requested review from davidwrighton, jkotas, max-charlamb and noahfalk September 12, 2025 00:18

Copilot AI reviewed Sep 12, 2025

View reviewed changes

...ractReader.Contracts/Contracts/ExecutionManager/ExecutionManagerCore.ReadyToRunJitManager.cs Show resolved Hide resolved

dotnet-policy-service bot assigned rcj1 Sep 12, 2025

rcj1 commented Sep 12, 2025

View reviewed changes

max-charlamb reviewed Sep 12, 2025

View reviewed changes

jkotas reviewed Sep 12, 2025

View reviewed changes

docs/design/datacontracts/ExecutionManager.md Outdated Show resolved Hide resolved

jkotas reviewed Sep 12, 2025

View reviewed changes

docs/design/datacontracts/ExecutionManager.md Outdated Show resolved Hide resolved

jkotas reviewed Sep 12, 2025

View reviewed changes

docs/design/datacontracts/ExecutionManager.md Outdated Show resolved Hide resolved

rcj1 added 2 commits September 12, 2025 14:25

code review

5e591f1

Merge branch 'main' into GetCodeHeaderData

41a9283

rcj1 marked this pull request as draft September 15, 2025 18:26

max-charlamb mentioned this pull request Sep 30, 2025

[cDAC] GetCodeHeaderData fork #120275

Open

dotnet-policy-service bot closed this Oct 15, 2025

Adding GetCodeHeaderData cDAC API #119609

Adding GetCodeHeaderData cDAC API #119609

Uh oh!

Conversation

rcj1 commented Sep 12, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

dotnet-policy-service bot commented Sep 12, 2025

Uh oh!

rcj1 commented Sep 12, 2025

Uh oh!

rcj1 Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

max-charlamb left a comment

Choose a reason for hiding this comment

Uh oh!

max-charlamb Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

max-charlamb Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

jkotas Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jkotas commented Sep 13, 2025

Uh oh!

rcj1 commented Sep 13, 2025

Uh oh!

rcj1 commented Sep 15, 2025

Uh oh!

dotnet-policy-service bot commented Oct 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rcj1 Sep 12, 2025 •

edited

Loading