[wasi] Enable EventPipe (FEATURE_PERFTRACING) for CoreCLR WASI

[lewing]

Description

CoreCLR WASI is built with EventPipe turned off. src/coreclr/CMakeLists.txt disables both features for CLR_CMAKE_TARGET_WASI:

  # EventPipe / diag-server PAL require sockets we have not validated
  # for the WASI bring-up; revisit once corerun.wasm runs.
  set(FEATURE_EVENT_TRACE 0)
  set(FEATURE_PERFTRACING 0)

src/coreclr/clr.featuredefines.props sets FeaturePerfTracing to false for TargetsWasi to match, so CoreLib doesn't call EventPipe QCalls that aren't implemented natively. corerun.wasm and wasihost now run the library and runtime test suites, so this can be revisited. Browser CoreCLR already has EventPipe enabled (#128745).

Impact

EventSource and in-process EventListeners work, but anything that goes through EventPipe doesn't:

• Outside Windows, EventSource.CurrentThreadActivityId and EventSource.SetCurrentThreadActivityId store the activity id only through EventPipeEventProvider.EventActivityIdControl, which is under #if FEATURE_PERFTRACING. On WASI the getter always returns Guid.Empty, so start/stop activity tracking has no visible effect. In System.Diagnostics.Tracing.Tests, ActivityTracking.StartStopCreatesActivity, ActivityFlowsAsync, SetCurrentActivityIdBeforeEventFlowsAsync and SetCurrentActivityIdAfterEventDoesNotFlowAsync fail for this reason.
• There are no EventPipe sessions, so no EventPipe-based tracing and no runtime events through EventPipe.

Seen in the CoreCLR WASI library test lanes on #134813, which quarantines those tests against this issue.

Possible approach

Enable FEATURE_PERFTRACING for WASI the way browser does (threadless EventPipe, FEATURE_PERFTRACING_DISABLE_THREADS). Leave the diagnostic server/IPC transport off until WASI sockets support is validated, then flip FeaturePerfTracing back on for WASI in clr.featuredefines.props. At a minimum, the activity-id storage and in-process sessions should work without the diagnostic server.

Note

This issue was drafted with the help of GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.