Add ProcessInfo3 diagnostic IPC command to include libc type or equivalent

[jander-msft]

For diagnostic tools that want to load an ICorProfilerCallback implementation using the diagnostic communication channel's AttachProfiler command need to understand the architecture and libc type (glibc vs musl libc) in order to provide a path to profiler assembly with the matching architecture and libc type.

For tools that are not running in the same process namespace (e.g. dotnet-monitor), this is nearly impossible to determine based on any of the information available while the target process is suspended. The latest process info (ProcessInfo2) command has OS and architecture information, but lacks libc type information. The environment block doesn't contain enough information to form a heuristic either; the following is an example environment block of an ASP.NET 6 Alpine container:

{
  "PATH":"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
  "HOSTNAME":"deploy-exampleapp-75cc844674-62w2q",
  "ASPNETCORE_URLS":"http://+:8080",
  "DOTNET_RUNNING_IN_CONTAINER":"true",
  "DOTNET_SYSTEM_GLOBALIZATION_INVARIANT":"true",
  "DOTNET_VERSION":"6.0.8",
  "ASPNET_VERSION":"6.0.8",
  "DOTNET_DiagnosticPorts":"/diag/port",
  "KUBERNETES_PORT_443_TCP_PORT":"443",
  "KUBERNETES_PORT_443_TCP_ADDR":"10.0.0.1",
  "KUBERNETES_SERVICE_HOST":"10.0.0.1",
  "KUBERNETES_SERVICE_PORT":"443",
  "KUBERNETES_SERVICE_PORT_HTTPS":"443",
  "KUBERNETES_PORT":"tcp://10.0.0.1:443",
  "KUBERNETES_PORT_443_TCP":"tcp://10.0.0.1:443",
  "KUBERNETES_PORT_443_TCP_PROTO":"tcp",
  "HOME":"/root"
}

The diagnostic pipe protocol should be updated with a new command (ProcessInfo3) that contains enough information to differentiate the libc type. Alternatively, this command could return the non-distribution specific runtime identifier (e.g. linux-x64, linux-musl-x64, osx-arm64, win-x86, etc), which is commonly used for packing assets for platform variations into the same package.

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

Issue Details

---

For diagnostic tools that want to load an ICorProfilerCallback implementation using the diagnostic communication channel's AttachProfiler command need to understand the architecture and clib type (glibc vs musl libc) in order to provide a path to profiler assembly with the matching architecture and clib type.

For tools that are not running in the same process namespace (e.g. dotnet-monitor), this is nearly impossible to determine based on any of the information available while the target process is suspended. The latest process info (ProcessInfo2) command has OS and architecture information, but lacks clib type information. The environment block doesn't contain enough information to form a heuristic either; the following is an example environment block of an ASP.NET 6 Alpine container:

{
  "PATH":"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
  "HOSTNAME":"deploy-exampleapp-75cc844674-62w2q",
  "ASPNETCORE_URLS":"http://+:8080",
  "DOTNET_RUNNING_IN_CONTAINER":"true",
  "DOTNET_SYSTEM_GLOBALIZATION_INVARIANT":"true",
  "DOTNET_VERSION":"6.0.8",
  "ASPNET_VERSION":"6.0.8",
  "DOTNET_DiagnosticPorts":"/diag/port",
  "KUBERNETES_PORT_443_TCP_PORT":"443",
  "KUBERNETES_PORT_443_TCP_ADDR":"10.0.0.1",
  "KUBERNETES_SERVICE_HOST":"10.0.0.1",
  "KUBERNETES_SERVICE_PORT":"443",
  "KUBERNETES_SERVICE_PORT_HTTPS":"443",
  "KUBERNETES_PORT":"tcp://10.0.0.1:443",
  "KUBERNETES_PORT_443_TCP":"tcp://10.0.0.1:443",
  "KUBERNETES_PORT_443_TCP_PROTO":"tcp",
  "HOME":"/root"
}

The diagnostic pipe protocol should be updated with a new command (ProcessInfo3) that contains enough information to differentiate the clib type. Alternatively, this command could return the non-distribution specific runtime identifier (e.g. linux-x64, linux-musl-x64, osx-arm64, win-x86, etc), which is commonly used for packing assets for platform variations into the same package.

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

[tommcdon]

cc @davmason

[hoyosjs]

cc @steveisok @lambdageek since you all had brought up a RID - holding event.

[lambdageek]

Can we add some kind of extensible ProcessInfo3 command with a request version field or a list of requested values or something? I know there's a 64k namespace for commands, but I'm not sure if it's a great idea to burn it up for what is at core an inherently extensible query.

[davmason]

I think it makes sense to add an extensible ProcessInfo command.

@jander-msft - for this particular use case, would it make more sense to build your profiler with a statically linked crt so you only have to have one per architecture?

[jander-msft]

@jander-msft - for this particular use case, would it make more sense to build your profiler with a statically linked crt so you only have to have one per architecture?

My immediate concerns with doing that would be licensing incompatibilities, severe bloating of the profiler assembly, possible compiler incompatibilities, and distro compatibility. Not sure about the other technical aspects since I haven't tried statically linking the crt.

[davmason]

I think those are all valid concerns, it might be worth trying it out since it should just be a few changes to the build. If you statically link the world then it should run on any distro as long as the architecture matches, but size on disk is a concern. I would be interested to see how drastically it changes the size. I would hope that the linker would be able to aggressively trim unused code.

For licenses, IANAL but libc++ is MIT and libstdc++ has a GPL exception to allow static linking so it should be fine from the CRT perspective.

In case it's not clear, I'm just trying to get more data about your scenario - the static linking discussion is independent of the new ProcessInfo command that I am in favor of. If static linking is not a good idea I'd like to understand why so in future conversations with profiler authors I can give the best advice.

[jkotas]

libc++ is MIT and libstdc++ has a GPL exception

You need a libc. glibc is GPL. It does not have any exceptions for static linking, and also it is not designed for static linking.

You would need to use musl that is alternative MIT libc implementation designed for static linking: https://www.musl-libc.org/how.html

[jander-msft]

I think those are all valid concerns, it might be worth trying it out since it should just be a few changes to the build. If you statically link the world then it should run on any distro as long as the architecture matches, but size on disk is a concern. I would be interested to see how drastically it changes the size. I would hope that the linker would be able to aggressively trim unused code.

For licenses, IANAL but libc++ is MIT and libstdc++ has a GPL exception to allow static linking so it should be fine from the CRT perspective.

In case it's not clear, I'm just trying to get more data about your scenario - the static linking discussion is independent of the new ProcessInfo command that I am in favor of. If static linking is not a good idea I'd like to understand why so in future conversations with profiler authors I can give the best advice.

I'm not opposed to it and will try to explore if this is a viable option for us. I had a brief discussion with one my teammates today about this and we think it has potential to solve a few problems, namely not needing to target specific crt, it might possibly reduce our package size at the end of it all if we are going from two profilers down to one + statically linked crt, and may give us a path to reduce dependencies in general. I think there are two main concerns that we have:

• if the crt has any dependencies on other libraries or if the other potential dependencies that our library has can be met on all Linux distros. It might be difficult to get into a position where all of our dependencies are statically linked. I still have to catalog them so I don't have data at this time.
• if the version of crt that we do statically link has any vulnerabilities, then we need a means to know when those vulnerabilities are disclosed and fixed. I'm sure that's a solved problem in some sense, but we'll want to tap into some automated way of being notified and somehow picking up the new version of the library