[wasm][wasi] CoreCLR-WASI follow-up TODOs from #130051 (PERFTRACING, exit-code marker, getexepath synth)

[lewing]

Tracks three deferred items called out during review of #130051 ([wasm][wasi] CoreCLR wasi onboarding). Each is an intentional stopgap with a clear removal/replacement condition; grouping them here so the corresponding review threads can be resolved with a concrete link. Related umbrella (test exclusions): #130064.

1. Wire WASI PERFTRACING and re-enable the diagnostics server PAL

src/coreclr/debug/debug-pal/CMakeLists.txt

if (NOT CLR_CMAKE_TARGET_WASI)
    # ds-ipc-pal-socket.c needs UNIX/TCP sockets; re-enable once
    # WASI PERFTRACING is wired.
    set(DEBUG_PAL_REFEREENCE_DIAGNOSTICSERVER ON)
endif()

DEBUG_PAL_REFEREENCE_DIAGNOSTICSERVER is currently forced off for WASI because ds-ipc-pal-socket.c depends on UNIX/TCP sockets that are not yet available. Re-enable once WASI PERFTRACING transport is wired up.

2. Remove the "WASM EXIT " stderr marker once exit-with-code is usable

src/coreclr/hosts/corerun/corerun.cpp

// ... when DOTNET_WASI_PRINT_EXIT_CODE=1, emit a "WASM EXIT <n>" marker on
// stderr matching Mono (src/mono/wasi/runtime/main.c); the WASI launcher in
// src/tests/Common/CLRTest.Execute.Bash.targets recovers the value from that.

The current toolchain collapses any non-zero Main return to host exit 1, so we emit a text marker that the test launcher parses. wasi:cli/exit already defines exit-with-code: func(status-code: u8), but it is gated @unstable(feature = cli-exit-with-code) in wasi-cli 0.2.x (wit/exit.wit). Once that feature stabilizes and the toolchain/host (wasi-libc, wasi-sdk, wasmtime) expose it so a non-zero code can be reported directly, this marker and the matching parser in CLRTest.Execute.Bash.targets can be removed.

3. Replace the CORE_ROOT-based executable-path synthesis in getexepath

src/native/minipal/getexepath.h

#elif defined(TARGET_WASI)
    // WASI has no /proc, no AT_EXECFN, and argv[0] is unreliable (often "/").
    // corerun.wasm is launched with the CORE_ROOT env var set to the directory
    // that holds CoreCLR ... The PAL only needs a path whose dirname is that
    // directory, so synthesize one here.
    const char* coreRoot = getenv("CORE_ROOT");
    ...
    return result; // <coreRoot>/corerun

This synthesizes a fake <CORE_ROOT>/corerun path because WASI exposes no reliable way to get the executable path. It works for the test host (which always sets CORE_ROOT) but is not a general host solution. Replace with a proper mechanism when WASI/wasi-libc exposes the executable path, or when a non-test host needs it.

---

Refs: #130051

Note

This issue was drafted by GitHub Copilot on behalf of the author.

[dotnet-policy-service]

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

[dotnet-policy-service]

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

[lewing]

Sequencing note for item 1 (WASI PERFTRACING): defer live diagnostics to WASI Preview 3

Recording the design rationale so it isn't lost.

What WASI has today (Preview 2): real BSD-style TCP sockets (AF_INET/AF_INET6 via wasi:sockets + the wasi-libc shim). pal_networking.c compiles for WASI and System.Net.Sockets already targets -wasi. So the socket transport genuinely exists.

The two catches:

• No AF_UNIX / Unix domain sockets — which is exactly the DiagnosticServer's default non-Windows transport (DS_IPC_PAL_UDS). UnixDomainSocketEndPoint.Wasi.cs throws PlatformNotSupportedException.
• No threads — every WASI socket is forced SOCK_NONBLOCK.

Feasibility tiers:

Tier	Result	Effort	Risk
File sessions	.nettrace to disk, no live tooling	small (stub DS PAL + flip the two gates)	Low
Live over TCP	dotnet-trace connects	Medium	ds-ipc-pal-socket.c's accept/poll has never run non-blocking + threadless
Live over UDS	n/a	Blocked	No AF_UNIX on WASI

The socket PAL could work in TCP mode (FEATURE_PERFTRACING_PAL_TCP -> AF_INET), and the DiagnosticServer already has a threadless mode (server_thread guarded by #ifndef PERFTRACING_DISABLE_THREADS, the way browser runs). The real unknown is making the PAL's listen/accept/poll cooperative (non-blocking + pumped on the WASI event loop), or using a connect-port model where the runtime dials out to the collector (no listen/accept).

Why wait for Preview 3: P3 brings native async (the component-model async ABI with future/stream and composable concurrency). That directly removes the awkward part: instead of forcing every socket into SOCK_NONBLOCK and hand-rolling a cooperative accept/poll pump, a P3 async socket read can suspend and resume without a dedicated thread. That is much closer to how ds-ipc-pal-socket.c already wants to behave (block-until-ready), so the PAL adaptation shrinks substantially. The connect-port model gets cleaner too.

Plan: keep PERFTRACING off for now (the two gates + this issue track it); revisit live diagnostics when Preview 3 async lands. File sessions remain a cheap interim option if anyone needs offline traces before then.

Note

This comment was drafted by GitHub Copilot on behalf of the author.