[cDAC]: Implement GetTypedByRefInfo, GetStringData, GetArrayData, GetBasicObjectInfo

[rcj1]

• Add two cDAC APIs on Object contract:

void GetStringData(TargetPointer address, out uint length, out uint offsetToFirstChar);
ulong GetSize(TargetPointer address);

• Add one cDAC API on RuntimeTypeSystem:

TypedByRefInfo GetTypedByRefInfo(TargetPointer typedByRef);

• Implement DacDbi APIs, slightly modifying out params to be more specific to each API
• Moving, renaming, and re-typing DebuggerIPCE_ObjectData

[Copilot]

Pull request overview

This PR extends the cDAC contracts and legacy DAC/DBI bridge to support additional object/typed-by-ref inspection APIs, and updates the CoreCLR DAC/DBI interface + right-side debugger plumbing to use more specific out-parameters (and a new object-data structure) for string/array/basic object queries.

Changes:

• Add TypedByRef data descriptor + IRuntimeTypeSystem.GetTypedByRefInfo(...) (with unit tests).
• Add IObject.GetStringData(...) and IObject.GetSize(...), and implement corresponding DAC/DBI entrypoints (GetStringData, GetArrayData, GetBasicObjectInfo, GetTypedByRefInfo) in the managed legacy bridge.
• Refactor debugger-side object data plumbing: replace DebuggerIPCE_ObjectData with DacDbiObjectData and update IDL/interface declarations and DI callers accordingly.

Show a summary per file

File	Description
src/native/managed/cdac/tests/UnitTests/MethodTableTests.cs	Adds unit tests validating GetTypedByRefInfo reads data/type fields correctly.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/IDacDbiInterface.cs	Updates managed COM projection signatures and introduces DacDbiArrayInfo.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/DacDbiImpl.cs	Implements the updated DAC/DBI APIs using cDAC contracts, with DEBUG cross-checks.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/DataType.cs	Adds DataType.TypedByRef descriptor name.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Data/TypedByRef.cs	New data descriptor for TypedByRef (Data + Type fields).
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs	Implements GetTypedByRefInfo in the RuntimeTypeSystem contract.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/Object_1.cs	Adds GetStringData and GetSize implementations in the Object contract.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Abstractions/Contracts/IRuntimeTypeSystem.cs	Adds public TypedByRefInfo and GetTypedByRefInfo API surface.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Abstractions/Contracts/IObject.cs	Adds public GetSize and GetStringData API surface.
src/coreclr/vm/datadescriptor/datadescriptor.inc	Adds TypedByRef to the CoreCLR cDAC data descriptor list.
src/coreclr/inc/dacdbi.idl	Updates IDL to the new out-parameter shapes and struct names.
src/coreclr/debug/inc/dbgipcevents.h	Removes DebuggerIPCE_ObjectData definition.
src/coreclr/debug/inc/dacdbistructures.h	Introduces DacDbiArrayInfo and DacDbiObjectData structures.
src/coreclr/debug/inc/dacdbiinterface.h	Updates DAC/DBI interface method signatures and associated comments.
src/coreclr/debug/di/rspriv.h	Switches DI-side storage/parameters from DebuggerIPCE_ObjectData to DacDbiObjectData.
src/coreclr/debug/di/process.cpp	Updates GetObjectInternal to use the new GetBasicObjectInfo signature.
src/coreclr/debug/di/divalue.cpp	Updates reference/object data initialization to call new DAC/DBI signatures for string/array/typed-byref.
src/coreclr/debug/daccess/dacdbiimpl.h	Updates DAC implementation declarations to new signatures.
src/coreclr/debug/daccess/dacdbiimpl.cpp	Updates DAC implementations for typed-byref/string/array/basic object queries.
docs/design/datacontracts/RuntimeTypeSystem.md	Documents the new TypedByRef descriptor + GetTypedByRefInfo API.
docs/design/datacontracts/Object.md	Documents GetStringData / GetSize additions and intended behavior.

Copilot's findings

• Files reviewed: 21/21 changed files
• Comments generated: 5

[github-actions]

Note

This review was generated by Copilot.

🤖 Copilot Code Review — PR #129200

Holistic Assessment

Motivation: Well-justified. The monolithic DebuggerIPCE_ObjectData struct forced every DacDbi API to pass a large struct even when only a few fields were relevant. Decomposing it into per-method parameters makes each API self-documenting and simplifies the cDAC managed implementation. Adding GetStringData, GetSize, and GetTypedByRefInfo to the cDAC contracts enables diagnostic scenarios that previously had no managed implementation.

Approach: The right approach — break the left-side (DAC) interface into specific parameters while the right-side (debugger) retains a convenience struct (DacDbiObjectData) with a union. The type narrowing from void*/SIZE_T to CORDB_ADDRESS/UINT eliminates 32/64-bit ambiguity in the struct. The DEBUG validation blocks comparing cDAC vs DAC results are thorough and consistent.

Summary: ⚠️ Needs Human Review. The code is structurally correct, follows established cDAC patterns, and the decomposition is clean. Two advisory concerns remain: missing output initialization in GetStringData (inconsistent with sibling methods) and a stale comment documenting a removed parameter. Neither is merge-blocking, but a human reviewer should confirm the defensive programming expectations for the cDAC layer.

---

Detailed Findings

⚠️ Missing output initialization in DacDbiImpl.GetStringData — inconsistent with siblings

File: src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/DacDbiImpl.cs (around line 3033)

GetStringData does not zero-initialize *pLength and *pOffsetToStringBase before the try block. If an exception occurs before the assignments (e.g., during GetMethodTableAddress or GetTypeHandle), the caller receives garbage values alongside a failure HRESULT.

All three sibling methods in this same PR properly initialize their outputs at the top:

• GetTypedByRefInfo: *pObjRef = 0; *pTypedByRefType = default;
• GetArrayData: *pIsValidArray = BOOL.FALSE; *pArrayInfo = default;
• GetBasicObjectInfo: *pIsValidRef = BOOL.TRUE; *pObjSize = 0; ...

Suggested fix:

public int GetStringData(ulong objectAddress, uint* pLength, uint* pOffsetToStringBase)
{
    *pLength = 0;
    *pOffsetToStringBase = 0;
    int hr = HResults.S_OK;
    ...

In practice the caller only invokes GetStringData after confirming the object is a string via GetBasicObjectInfo, so the risk is low. But it's inconsistent with the defensive pattern used everywhere else in this PR. Advisory, not merge-blocking.

⚠️ Stale type parameter in GetBasicObjectInfo comment

File: src/coreclr/debug/inc/dacdbiinterface.h (lines 1771–1773)

The comment block still documents a type input parameter that was removed from the signature:

//     input:  objectAddress    - address of the object for which we want information
//             type             - the basic type of the object (we may find more specific type
//                                information for the object)

The actual signature no longer has type:

virtual HRESULT STDMETHODCALLTYPE GetBasicObjectInfo(
    CORDB_ADDRESS objectAddress, OUT BOOL * pIsValidRef, ...);

The two lines documenting type should be removed. Advisory, not merge-blocking.

💡 Inconsistent error message in Object_1.GetSize

File: src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/Object_1.cs (line 196)

GetSize throws "Address represents a free object" while all other methods in Object_1 (GetStringValue, GetStringData, GetArrayData) use "Address represents a set-free object" for the same condition (mt == TargetPointer.Null). The design doc pseudocode also uses "set-free object". Consider aligning for consistency.

✅ cDAC contract APIs do not require API review

Per cdac.instructions.md, new APIs on IContract implementations do not need API review for .NET 11 dev branches. The SDK version (11.0.100-preview.5) confirms this applies. The DacDbi interface is internal/unstable.

✅ process.cpp concern from prior automated review is pre-existing

I verified that GetObjectInternal in process.cpp only calls GetBasicObjectInfo without subsequently filling stringInfo/arrayInfo in the DacDbiObjectData union. However, tracing the old code reveals that the previous InitObjectData also never initialized the union's string/array fields. This PR preserves identical behavior. The CordbObjectValue::Init() path that reads stringInfo.offsetToStringBase was already operating on uninitialized data in the old code — this is not a regression introduced by this PR.

✅ TypedByRef data descriptor and contract implementation

The TypedByRef data descriptor in datadescriptor.inc correctly uses offsetof(TypedByRef, data) and offsetof(TypedByRef, type). The Data.TypedByRef class follows the standard IData<T> pattern. The RuntimeTypeSystem_1.GetTypedByRefInfo reads both fields via ProcessedData.GetOrAdd<>. Unit tests cover both non-null and zero-value scenarios.

✅ CORDB_ADDRESS type migration for objRef is correct

All comparison sites now use (CORDB_ADDRESS)NULL instead of bare NULL. The two MemoryRange callsites in InitRef/GetPointerData correctly introduce an intermediate void* pObjRef = CORDB_ADDRESS_TO_PTR(m_info.objRef) to preserve the semantics where the code needs a pointer-sized local to write into.

✅ GetSize min-object-size logic is semantically correct

The cDAC computes minObjectSize = 2 * pointerSize + ObjectHeaderSize and returns max(size, minObjectSize). The C++ DAC applies PtrAlign(size) only for strings when size < MIN_OBJECT_SIZE. These are equivalent because the VM guarantees baseSize >= MIN_OBJECT_SIZE for non-variable-size objects. The DEBUG validation block would catch any discrepancy.

�� No unit tests for GetStringData or GetSize

The PR adds good unit tests for GetTypedByRefInfo. GetStringData and GetSize lack dedicated contract-level unit tests. The DEBUG validation provides runtime coverage, but explicit tests would strengthen confidence in edge cases (empty strings, minimum-size objects). Suitable as a follow-up.

---

Model: claude-opus-4.6

Generated by Code Review for issue #129200 · ● 7.5M · ◷

[Copilot]

Copilot's findings

• Files reviewed: 21/21 changed files
• Comments generated: 6