[cDAC] GetCodeHeaderData fork

[max-charlamb]

fork of #119609 with GCInfo decoder

• Adding GetCodeHeaderData cDAC API
• Implementing unwind data size on platforms other than x86 in helper class
• required additions to hot/cold lookup helpers
• Implements IGCInfo contract to decode GCInfo
  • Currently supports x64, arm64, and arm. I plan to move the existing x86 GCInfo decoding to this new contract, but want to make that a separate PR.

[dotnet-policy-service]

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

[Copilot]

Pull Request Overview

This PR implements the GetCodeHeaderData method and adds GC info decoder functionality to the contract DAC (cDAC) system. It introduces a new GCInfo contract with platform-specific implementations for decoding garbage collection metadata from native code.

Key Changes:

• Implements GetCodeHeaderData method with proper type safety and error handling
• Adds a comprehensive GCInfo contract with decoder capabilities for AMD64, ARM64, and ARM architectures
• Extends ExecutionManager with new methods for method region info, JIT type detection, and method descriptor lookup

Reviewed Changes

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

Show a summary per file

File	Description
SOSDacImpl.cs	Implements GetCodeHeaderData with GCInfo decoder integration and debug assertions
ISOSDacInterface.cs	Updates interface signature and adds supporting data structures
CachingContractRegistry.cs	Registers the new GCInfo contract factory
GCInfo contract files	Complete GCInfo decoder implementation with platform-specific traits
ExecutionManager files	Extends with method region info, JIT type detection, and entrypoint resolution
Data structure files	Adds UnwindInfo, PortableEntryPoint, and related helper classes

Comments suppressed due to low confidence (1)

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/GCInfo/PlatformTraits/IGCInfoTraits.cs:1

• Corrected spelling of 'ENCBACE' to 'ENCBASE'.

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

[Copilot]

Pull Request Overview

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

[davidwrighton]

How do we handle the interpreter. It also uses the GC info.

[max-charlamb]

Mirroring how the runtime handles this case, I believe it is acceptable to have a different entrypoint to decode the 'standard platform' code and the interpreter code.

• IGCInfoHandle IGCInfo.DecodeGCInfo(TargetPointer gcInfoAddress, uint gcVersion)
• IGCInfoHandle IGCInfo.DecodeInterpreterGCInfo(TargetPointer gcInfoAddress, uint gcVersion)

I don't believe this can be encapsulated in the current format as the ExecutionManager calls into the GCInfo contract to find the method region info. If the GCInfo contract differentiated between interpreted and jitted code, then it would need to call into ExecutionManager creating a cyclic dependency.

[am11]

Shall we use similar arch-specific structure as: src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/StackWalk/Context/{arch}/{arch}Unwinder.cs or bring that to this (single directory) plan?

[max-charlamb]

I don't have a strong feeling either way. I didn't make /{arch}/ subdirectories here because each platform only has a single file. In the future we may have versions of traits and multiple files. I think it would make sense to have specific directories.