`dotnet-trace collect-linux` fails to collect runtime events when using the IPC mapping even with patched recordtrace lib

[hoyosjs]

Description

When using dotnet-trace collect-linux to collect traces from a Native AOT application with runtime event providers (e.g., Microsoft-DotNETRuntime), the tool never receives an EventPipe message specifying the tracepoints to register. The trace session starts without error but produces an empty or incomplete trace file, lacking any events from the runtime providers. This is after adding the expected IPC mapping and using one-collect's latest commit (2b083e1eac3b5766d9687431edebdfec7afa8374). This issue appears to be specific to the librecordtrace.so FFI code path and does not reproduce when using the managed EventPipe collect path on AOT apps or when using the FFI path using dotnet trace against a regular .NET app. The native AOT collection also seems to work if I use record-trace directly.

Steps to Reproduce

1. Publish a .NET application with Native AOT (dotnet publish -r linux-x64 -p:PublishAot=true -p:EventSourceSupport=true).
2. Run the AOT application.
3. Attempt to collect a trace:

   dotnet-trace collect-linux -p <pid> --providers gc-collect

4. The produced trace doesn't is empty.
5. Stop collection — the resulting .nettrace file is empty or contains only header/metadata.

Expected Behavior

dotnet-trace collect-linux should successfully receive runtime provider events from AOT applications, the same way it does for standard CoreCLR apps. The recordtrace FFI layer should correctly register and invoke the event callback.

Actual Behavior

No callback is ever invoked. The session appears to hang indefinitely waiting for events that never arrive. The issue is isolated to the recordtrace FFI integration — other collection mechanisms (if available) are not affected.

Additional Context

• Needs investigation into whether the AOT runtime's EventPipe implementation signals readiness differently than CoreCLR.

[hoyosjs]

Some more investigation: I can repro the same issue on coreclr when I disable W^X, but it works fine with the standalone recordtrace.