[cDAC] Remove GetObjectContents DacDbi API

[Copilot]

Delete this API, we don't need it. Object size is already available through GetBasicObjectInfo.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the CoreCLR DAC/DBI contract and its managed “legacy/cDAC” projection by removing the GetObjectContents API and adjusting delegate-related APIs to operate on raw CORDB_ADDRESS object addresses, with corresponding right-side updates to stop depending on GetObjectContents.

Changes:

• Removes GetObjectContents from the native IDL/header contract and from the managed legacy/cDAC COM surface.
• Switches IsDelegate / delegate helper methods to accept CORDB_ADDRESS instead of VMPTR_Object, and updates call sites accordingly.
• Refactors right-side heap reference creation to use the object address directly (no DAC roundtrip to “deconstruct” a VMPTR).

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/IDacDbiInterface.cs	Removes the managed COM interface entry for GetObjectContents; renames IsDelegate parameter for clarity.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/DacDbiImpl.cs	Drops the legacy fallback wrapper for GetObjectContents; updates IsDelegate signature to match the contract change.
src/coreclr/inc/dacdbi.idl	Removes GetObjectContents from the IDL and changes delegate-related methods to use CORDB_ADDRESS.
src/coreclr/debug/inc/dacdbiinterface.h	Removes GetObjectContents from the C++ interface and updates delegate method signatures/docs.
src/coreclr/debug/di/rspriv.h	Updates right-side helper signature to accept an object address instead of VMPTR_Object.
src/coreclr/debug/di/divalue.cpp	Removes GetObjectContents usage; passes CORDB_ADDRESS directly for delegate queries/target extraction.
src/coreclr/debug/daccess/dacdbiimpl.h	Updates DAC implementation declarations for the delegate APIs; removes GetObjectContents declaration.
src/coreclr/debug/daccess/dacdbiimpl.cpp	Removes GetObjectContents implementation; updates delegate APIs to operate on raw addresses.

Copilot's findings

Comments suppressed due to low confidence (1)

src/coreclr/inc/dacdbi.idl:364

• This change removes/reshapes methods on IDacDbiInterface (vtable layout + parameter types). That’s a protocol-breaking change; without bumping kCurrentDacDbiProtocolBreakingChangeCounter (src/coreclr/debug/inc/dacdbistructures.h:676) older DBI/DAC pairs could still pass CheckDbiVersion and then call mismatched vtable slots, leading to crashes/corruption. Please increment the counter and document the new value in the DbiVersion comment block.

    HRESULT IsVmObjectHandleValid([in] VMPTR_OBJECTHANDLE vmHandle, [out] BOOL * pResult);
    HRESULT IsWinRTModule([in] VMPTR_Module vmModule, [out] BOOL * pIsWinRT);
    HRESULT GetHandleAddressFromVmHandle([in] VMPTR_OBJECTHANDLE vmHandle, [out] CORDB_ADDRESS * pRetVal);

    // Object Contents and Monitor
    HRESULT GetThreadOwningMonitorLock([in] VMPTR_Object vmObject, [out] struct MonitorLockInfo * pRetVal);
    HRESULT EnumerateMonitorEventWaitList([in] VMPTR_Object vmObject, [in] FP_THREAD_ENUMERATION_CALLBACK fpCallback, [in] CALLBACK_DATA pUserData);

    // Attach State

• Files reviewed: 8/8 changed files
• Comments generated: 2

[Copilot]

Copilot's findings

• Files reviewed: 8/8 changed files
• Comments generated: 1

[max-charlamb]

Is there a reason to move away from VMPTR_Object in favor of the not type safe CORDB_ADDRESS?

I see in this code path it is a bit redundant, but it seems reasonable to thread all of the object creation through the same method for the purpose of address validation (if we want that).

It looks like we could greatly reduce the PR diff if we limit this change to removing the method.

If we still want to change the VMPTR_Object to CORDB_ADDRESS could we do it in a separate PR and handle all the uses uniformly?

[rcj1]

We need to use CORDB_ADDRESS instead of the VMPTR because VMPTR is not designed to allow us to grab the raw address in the DBI. (Well, technically theres VmPtrToCookie, but I’m not sure it was designed for this.) I am thinking about a way to handle this uniformly - maybe we can provide a conversion operator from VMPTR to another opaque handle type that we only use on signatures.

[rcj1]

Actually, maybe there is a good way to keep the type safety in the general case. But nevertheless, as this path started out with a raw CORDB_ADDRESS, I don’t think we’re really losing much here.

[rcj1]

Eh, the thing is with the status quo shape we could verify the object if we wanted to. I wonder if we could just leave this as-is and replace the DBI API with a conversion operator.