Add ICorDebugDataTarget5 with GetTargetInfo and implement it in ShimDataTarget

[rcj1]

Introduce a new ICorDebugDataTarget5 interface exposing GetTargetInfo, which reports the target's processor architecture and operating system.

Implement GetTargetInfo once in the shared ShimDataTarget base class

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 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]

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 extends the CoreCLR debugging COM contracts by adding ICorDebugDataTarget5 with a GetTargetInfo method, and wires up an implementation on the shared ShimDataTarget base used by the shim data targets.

Changes:

• Add ICorDebugDataTarget5 plus supporting CorDebugTarget* enums/struct in cordebug.idl, and update the prebuilt MIDL outputs (cordebug.h, cordebug_i.cpp).
• Export the new IID_ICorDebugDataTarget5 from mscordac on Unix.
• Implement ICorDebugDataTarget5 and QueryInterface support in ShimDataTarget, with a shared GetTargetInfo implementation.

Show a summary per file

File	Description
src/coreclr/pal/prebuilt/inc/cordebug.h	Adds the generated header definitions for ICorDebugDataTarget5 and CorDebugTargetInfo.
src/coreclr/pal/prebuilt/idl/cordebug_i.cpp	Adds the generated IID_ICorDebugDataTarget5 GUID definition.
src/coreclr/inc/cordebug.idl	Defines the new public COM interface ICorDebugDataTarget5 and the CorDebugTargetInfo types.
src/coreclr/dlls/mscordac/mscordac_unixexports.src	Exports IID_ICorDebugDataTarget5 from mscordac on Unix.
src/coreclr/debug/di/shimdatatarget.h	Adds ICorDebugDataTarget5 to the shim data target base class and declares GetTargetInfo.
src/coreclr/debug/di/shimdatatarget.cpp	Implements QueryInterface support for ICorDebugDataTarget5 and implements GetTargetInfo.

Copilot's findings

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

[Copilot]

Copilot's findings

Comments suppressed due to low confidence (2)

src/coreclr/debug/di/shimdatatarget.cpp:107

• GetTargetInfo should honor the data-target error/neutered state like the other data-target methods (m_hr != S_OK). Without this, callers can successfully query target info after Dispose/SetError, contradicting the class contract in shimdatatarget.h.

HRESULT STDMETHODCALLTYPE ShimDataTarget::GetTargetInfo(CorDebugTargetInfo * pTargetInfo)
{
    if (pTargetInfo == NULL)
    {
        return E_INVALIDARG;
    }

src/coreclr/debug/di/shimdatatarget.cpp:114

• GetTargetInfo uses HOST_* defines to report architecture. In this codebase, TARGET_* is used to describe the architecture the shim is built for (see other data-target methods like GetPlatform), while HOST_* can differ for cross-builds; using HOST_* can misreport the target architecture.

#if defined(HOST_X86)
    pTargetInfo->arch = CORDB_ARCH_X86;
#elif defined(HOST_AMD64)
    pTargetInfo->arch = CORDB_ARCH_AMD64;
#elif defined(HOST_ARM)

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

[noahfalk]

What pushes us to make a new API vs using the one we already have?
https://learn.microsoft.com/en-us/dotnet/core/unmanaged-api/debugging/icordebug/icordebugdatatarget-getplatform-method

[rcj1]

Currently, implementations of the API do not distinguish between Mac and Linux. If we ever needed to distinguish the two, we would not be able to distinguish say a Mac with an old implementation that returns POSIX_XXX, from a Linux with either an old or a new implementation. I also like the (arch, OS) API as opposed to one which lists all the possible combinations - especially when we often care about only one element at a time.

[max-charlamb]

I'm skeptical we need to add this new public surface area right now, especially considering this is implemented for in repo use only. What APIs need this? Do we need to distinguish between MacOS and Linux today?

[rcj1]

I don't see us distinguishing Mac from Linux anywhere at the moment, but we really should be able to distinguish them, and we really should not rely on this surface where we have to do X different checks just to check if we are ARM64, for example. The idea is that @hoyosjs would have the rest of the data targets implement this API as well, and that if needed we can fall back to the old API.