[release/10.0] [EventPipe] Add dotnet_ipc_created mapping

[github-actions]

Backport of #123779 to release/10.0

/cc @mdh1418

Customer Impact

• Customer reported
• Found internally

User_events support was added in .NET 10. The officially supported way to enable user_events is through One-Collect's record-trace (which dotnet-trace wraps around). Record-trace relied on an implementation detail of W^X that NativeAOT doesn't support since it doesn't support PerfMaps (see microsoft/one-collect#226), so it was belatedly discovered that user_events doesn't work for NativeAOT.

Through discussions in microsoft/one-collect#226, this dotnet_ipc_created mapping with no permissions (PROT_NONE) was found as an acceptable minimal OS interaction to signal when the .NET process' diagnostic ports are available.

Regression

• Yes
• No

Testing

I tested the User_events runtime tests against a locally built record-trace based on microsoft/one-collect#229 in both CoreCLR and NativeAOT on my WSL2 instance.

Risk

Low. The mapping being introduced has minimal permissions as it is a private mapping created with PROT_NONE.

[mdh1418]

cc: @jkotas @noahfalk @lateralusX

[mdh1418]

I will test the official build on main to double check we aren't missing headers that the logic is guarded under.

[jkotas]

I will test the official build on main to double check we aren't missing headers that the logic is guarded under.

Note that we upgraded the headers in main to newer Linux version. main has Ubuntu 20 / glibc 2.31, .NET 10 has Ubuntu 18 / glibc 2.27. You may want to check the backport as well.

Alternatively, you can simplify the ifdefs to just HOST_LINUX so that the build breaks in case we are building against headers that are too old. We do not really care about supporting that.

[steveisok]

I will test the official build on main to double check we aren't missing headers that the logic is guarded under.

Holding off on merging until we have a chance to validate.

[mdh1418]

Validated off of the VMR main's corresponding code flow built artifacts dotnet/dotnet#4680.

I built a NativeAOT app doing GC work. It generated the dotnet_ipc_created mapping, and the latest record-trace was able to discover the mapping, send an IPC command, and collect GC events from that NativeAOT app.

Is there a straightforward way to test how the VMR would build these backport changes in it's backport branch before merging this backport PR? Or is letting this flow and validated against the 10.0.3xx branch the simplest way?

---

Copilot CLI thinks it should be compatible with Ubuntu 18/glibc 2.27

The dotnet_ipc_created feature uses syscall(__NR_memfd_create, ...) directly (not the glibc wrapper). Here's the compatibility breakdown:

Requirement	Minimum Version	Ubuntu 18.04 (glibc 2.27)	Status
memfd_create syscall	Linux kernel 3.17	Kernel 4.15	✅
__NR_memfd_create in headers	linux-libc-dev from kernel 3.17+	Defined as syscall 319 (x86-64)	✅
sys/mman.h	Standard	Available	✅
sys/syscall.h	Standard	Available	✅

Conclusion: The backport to .NET 10 (Ubuntu 18.04 / glibc 2.27) should work because:

1. The syscall number __NR_memfd_create comes from kernel headers (linux-libc-dev), not glibc
2. Ubuntu 18.04's kernel 4.15 headers include this syscall number
3. The CMake check check_symbol_exists(__NR_memfd_create sys/syscall.h HAVE_MEMFD_CREATE) will succeed

[steveisok]

Is there a straightforward way to test how the VMR would build these backport changes in it's backport branch before merging this backport PR? Or is letting this flow and validated against the 10.0.3xx branch the simplest way?

There are multiple stages... Simplifying a bit, the first one is does change pass out of runtime (this PR), the second one is the forward flow into the VMR, and the backflow back to runtime closes the loop that you are looking for. If you were able to do represent the backflow already, that's a strong indicator that this change can go in with confidence.

[steveisok]

@mdh1418 if you're all good, please approve and I'll merge it.

[jkotas]

Is there a straightforward way to test how the VMR would build these backport changes

The easiest way is to submit test-only PR to VMR with the change, trigger /azp run dotnet-unified-build-full and download the bits to tests from the PR artifacts. (Example dotnet/dotnet#3349)

If you want to do it locally, you can build in the official build docker image for .NET 10 (https://github.com/dotnet/runtime/blob/release/10.0/docs/workflow/using-docker.md has instructions) and then patch your SDK setup with your private or point SDK to use your private. The instructions for using NativeAOT privates at https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/nativeaot.md#building-packages are broken currently - you have to use workaround from #119166 (comment) .

[mdh1418]

Validated against the 10.0.4 artifacts from the VMR test pr, thanks Jan!

[hoyosjs]

/ba-g known failures against a release branch