[tomblanchard312]

Summary

• enumerate another FreeBSD process's vnode mappings with KERN_PROC_VMMAP
• return full module paths and base addresses through the existing PAL ProcessModules list
• enable dbgshim to resolve libcoreclr.so and the matching libmscordbi.so during runtime startup

Validation

Built libdbgshim.so natively on FreeBSD 15.1 amd64 with LLVM 19 and used it with NetCoreDbg 3.2.0 plus the FreeBSD .NET SDK/runtime 9.0.115/9.0.14.

A dependency-free DAP smoke test launched a net9.0 C# console program, stopped at the requested Program.cs source breakpoint, continued, and observed both exit code 0 and the terminated event.

Before this change, the FreeBSD PAL had neither the macOS nor procfs module-enumeration path. dbgshim received only the module basename, failed with E_INVALIDARG, and returned a null ICorDebug pointer.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[tomblanchard312]

@dotnet-policy-service agree

[tomblanchard312]

Follow-up native .NET 10 validation on FreeBSD 15.1-RELEASE-p6 amd64. I built dbgshim with #6183 applied to the diagnostics sources in the .NET 10.0.110 VMR and built NetCoreDbg from Samsung/netcoredbg#260 using LLVM 19 and matching CoreCLR 10.0.10 headers.

As an ordinary user, the existing DAP smoke test launched a native net10.0 console fixture, hit its source breakpoint, continued, and exited 0. In Code - OSS 1.138.0, the same fixture stopped at Program.cs:3 and showed the expected stack frame and locals (left=20, right=22) before continuing to exit 0.

This run covers native launch. Attach, stepping, and managed exception validation are pending.

[tomblanchard312]

I tried to reproduce the timeout in SOS_linux-x64_Debug-Net10 from Azure Pipelines build 1662730 using the original Helix test payload and Linux x64 .NET 10.0.10.

• PrintException_TaskExceptionChain with tasknestedexception/DotnetDump/SingleFile/net10/Dump/Workstation/Heap passed 10 consecutive isolated runs, each with a fresh dump (395–493 ms).
• The full .NET 10 shard passed locally in an Ubuntu 22.04 container with LLDB and two workers (424 passed, 55 skipped, 0 failed). The same case passed in 395 ms.
• Running the exact single-file debuggee directly, createdump wrote the heap dump in 153 ms.

The original Helix work item kept reporting that case with unchanged progress until the two-hour timeout. The local runs used the host Linux kernel and did not reproduce the stall. The hosted log does not identify whether it stalled during dump capture, analyzer startup, or an SOS command.

Could a maintainer with Azure Pipelines access rerun the failed Tests Helix linux-x64 Debug job on build 1662730 and share the new attempt or Helix work-item link? Azure DevOps denied my retry request.