GetProcessInfo3 diagnostic command

[jander-msft]

Add the GetProcessInfo3 command to the diagnostic server. This allows for retrieving the portable runtime identifier which informs diagnostic tools which variants of native libraries may be loaded into the target process. The portable runtime identifier is statically calculated at compile time based on the build target information for the libraries that link in the diagnostic server.

Corresponding diagnostics change: dotnet/diagnostics#3985

closes #74476

[ghost]

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

Issue Details

---

Add the GetProcessInfo3 command to the diagnostic server. This allows for retrieving the portable runtime identifier which informs diagnostic tools which variants of native libraries may be loaded into the target process. The portable runtime identifier is statically calculated at compile time based on the build target information for the libraries that link in the diagnostic server.

Author:	jander-msft
Assignees:	-
Labels:	area-Diagnostics-coreclr
Milestone:	-

[jander-msft]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 87707 in repo dotnet/runtime

[jkotas]

/azp run

[jander-msft]

Could I get a new build ("/azp run") for the current set of changes? Seems some Azure service hiccupped while this one was starting.

[azure-pipelines]

You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list.

[jkotas]

/azp run runtime

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jander-msft]

With the prior change, all jobs and tests were green except one where the new test was erroneously included. That was fixed in the latest commit. With that, I think this is ready for review.

[jander-msft]

@tommcdon could I get someone from diagnostics to review this?

[davmason]

LGTM, but I want to give @lateralusX a chance to look before mergin

[lateralusX]

Sorry, was out on vacation but changes LGTM! One thought I had is that the portable rid will not be as specific as the OS where Mono will give you different identifiers for iOS/tvOS and Android, the portable rid will place all of them under each platforms inherited rid, so iOS/tvOS will present itself as unix and Android as linux-bionic, but I guess is fine, and it is always possible to take a look at the OS parameter to get more details around the specific OS. One platform that might not give you the right portable rid with current change is maccatalyst that should present itself similar to iOS (https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.NETCore.Platforms/src/runtime.json#L2296), but will with current change present itself as osx, so that probably needs to be adjusted. Having that said, maccatalyst is not currently included as an OS either, so when adjusting that we should probably also adjust that in https://github.com/dotnet/runtime/blob/main/src/native/eventpipe/ep-event-source.c#L15.

[jander-msft]

The intent of this portable RID is to provide a mechanism to differentiate the C library types (e.g. gnu, musl, bionic for Linux) for the target without having to know the specifics of the target so that native libraries with a portable notion could be loaded and executed in the target process; portable meaning not taking a hard dependency on specific distribution or version. We could have reported the literal C library type instead, but then we'd have to make up monikers or completely ignore other targets. Additionally, there seems to be support via library systems (e.g. NuGet) for providing libraries using this generic portable RID notion.

That being said, if something that is targeting a maccatalyst target needs to build a native library that is more specific than iOS-x64 or iOS-arm64 in order for it to be loaded and excitable, then these specifically can be carved out but should be done so in the most generic terms. For example, it seems that Void Linux supports both musl and gnu libc, but by default has gnu libc; it's RID in this scheme should not be void-x64 but should be linux-x64 or linux-musl-x64.