SunOS process and thread support #105403

gwr · 2024-07-24T14:38:56Z

Read binary psinfo for System.Diagnostic.Process on SunOS (Solaris or illumos).
No failures in System.Diagnostic.Process.Tests (but lots of skip)

BTW, I tried rebasing on main from Mon. this week and ran into problems downloading stuff.
Not sure why, but it didn't seem to have anything to do with my changes.

am11 · 2024-07-24T15:37:42Z

Lets drop the changes which are already submitted in other PRs.

src/coreclr/pal/src/exception/signal.cpp

src/libraries/Common/src/Interop/SunOS/procfs/Interop.ProcFsStat.cs

src/libraries/System.Diagnostics.Process/src/System.Diagnostics.Process.csproj

src/libraries/System.Diagnostics.Process/src/System/Diagnostics/ProcessThread.SunOS.cs

src/libraries/System.Diagnostics.Process/tests/ProcessTests.cs

src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.BSD.cs

am11 · 2024-07-24T15:59:34Z

Good start! I've left initial feedback, which I anticipate the maintainers will point out. :)

gwr · 2024-07-24T18:48:41Z

Good start! I've left initial feedback, which I anticipate the maintainers will point out. :)

Thanks. I had not yet seen #105207 when I opened this. I think @AustinWise and I should figure out how to get the prerequisite fixes shown there (and here) all integrated, and then I'll rebase the last parts of this onto that.

src/libraries/System.Diagnostics.Process/src/System/Diagnostics/ProcessManager.SunOS.cs

src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.SunOS.cs

gwr · 2024-07-24T21:41:26Z

Lets drop the changes which are already submitted in other PRs.

I'd love to, but I do not see a way to do "stacked" PRs, where one PR targets the branch of another PR.
If I drop the prerequisite changes then things break. Suggestions welcome.

am11 · 2024-07-24T22:18:57Z

Create a local branch feature/illumos-port with all the miscellaneous changes. Then keep this branch only for System.Diagnostics.Port changes. You can git cherry-pick <spaces-separated commit hashes> across the branches.

risc-vv · 2025-07-10T14:55:40Z

RISC-V Release-CLR-QEMU: 9082 / 9112 (99.67%)

=======================
      passed: 9082
      failed: 2
     skipped: 597
      killed: 28
------------------------
 TOTAL tests: 9709
VIRTUAL time: 37h 26min 40s 438ms
   REAL time: 38min 9s 841ms
=======================

report.xml, report.md, failures.xml, testclr_details.tar.zst

RISC-V Release-CLR-VF2: 9083 / 9113 (99.67%)

=======================
      passed: 9083
      failed: 2
     skipped: 597
      killed: 28
------------------------
 TOTAL tests: 9710
VIRTUAL time: 11h 43min 10s 548ms
   REAL time: 47min 22s 50ms
=======================

report.xml, report.md, failures.xml, testclr_details.tar.zst

RISC-V Release-FX-QEMU: 278604 / 279696 (99.61%)

=======================
      passed: 278604
      failed: 1083
     skipped: 39
      killed: 9
------------------------
 TOTAL tests: 279735
VIRTUAL time: 29h 11min 36s 714ms
   REAL time: 1h 11min 4s 97ms
=======================

report.xml, report.md, failures.xml, testclr_details.tar.zst

RISC-V Release-FX-VF2: 309598 / 311334 (99.44%)

=======================
      passed: 309598
      failed: 1729
     skipped: 39
      killed: 7
------------------------
 TOTAL tests: 311373
VIRTUAL time: 21h 13min 12s 292ms
   REAL time: 2h 17min 0s 803ms
=======================

report.xml, report.md, failures.xml, testclr_details.tar.zst

Build information and commands

GIT: 3a905a16032b7a90d59d66c343b51123cb3e9f29
CI: d6c9c1ab3a7411819463edc05ded301e89ba586a
REPO: dotnet/runtime
BRANCH: main
CONFIG: Release
LIB_CONFIG: Release

* Fix illumos compile error at minipal/debugger.c:127 dotnet/runtime/src/native/minipal/debugger.c:127:5: error: implicit declaration of function 'snprintf' [-Werror=implicit-function-declaration] 127 | snprintf(statusFilename, sizeof(statusFilename), "/proc/%d/status", getpid()); | ^~~~~~~~ * Fix illumos compile error in minipal/thread.h src/native/minipal/thread.h:73:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 73 | tid = (size_t)(void*)pthread_self(); | ^~~~~~~~~~~~~~~~~~~~~ * Fix illumos compile error in native/libs/System.Native/pal_mount.c src/native/libs/System.Native/pal_mount.c:164:38: error: 'struct statvfs' has no member named 'f_type' 164 | *formatType = (int64_t)(stats.f_type); | ^ * Fix illumos compile error in coreclr/pal/src/thread/thread.cpp /home/gwr/dotnet/runtime/src/coreclr/pal/src/thread/thread.cpp:1367:5: error: 'cid' was not declared in this scope 1367 | cid = CLOCK_THREAD_CPUTIME_ID; | ^~~

gwr · 2025-07-14T02:53:48Z

I'm still not sure how to get the System.Diagnostics.Process/test stuff onto my test host and run it. I've tried to follow the workflow documents but those don't say much about cross builds like I have to do. Cook-book commands would be a great help. Thx!

am11 · 2025-07-14T04:23:20Z

There is no easy way to run libraries tests when we are in the middle of porting shared framework (itself) and sdk/msbuild aren't fully functional on the platform. The improvised way involves gathering references and assemblies then feed it to dotnet(1) same as how the test command line gets serialized on linux. If you are unfamiliar with sdk/msbuild commands, it complicates things further.

gwr · 2025-07-14T13:14:45Z

OK, so I'm trying to become more familiar, and have tried looking at how this works on linux.
I can copy over simple DLLs and run them (eg. HelloWorld, and my procinfo test).
My current obstacle is that the xunit.console.dll is no longer there (how I used to run tests).
The docs say to use "dotnet test", but that's not there yet and I'm not sure what to cross build and how to copy it into place to make that work so I can run the S.D.Process tests again.

I'm building like this:

export CMAKE_MAKE_PROGRAM=/usr/local/bin/cmake
export ROOTFS_DIR=/crossrootfs/x64
./build.sh clr+libs+libs.tests -c Debug -cross -os illumos -gcc --bootstrap

and then copying this over to the illumos test system and unpack:

artifacts/packages/Debug/Shipping/dotnet-runtime-10.0.0-dev-illumos-x64.tar.gz

That much gives me a working dotnet command, but I don't see any SDK stuff.
I could use help getting the SDK built and copied over. I don't see that case covered in the workflow docs. I only see instructions for native build.

am11 · 2025-07-14T16:43:53Z

I think your test program from #34944 (comment) is sufficient for now. Just add process spawn case and if that works, we are good to go for this initial iteration.

New platform (especially new operating system as opposed to new arch) isn't a smooth sail and engineering doesn't pay too much attention to it during larger refactoring (mainly because it's once in a lifetime thing for a given platform). Once, System.Diagnostics.Process and the remaining two libs are ported, we can get a full blown SDK though source-build. Then it'd be a matter of extracting that SDK at root of the repo cloned in illumos based OS and running $repo_root/dotnet.sh build -t:Test <path to test project dir>. With that, faster iterations by running various test suites, finding out issues and resolving them would be seamless.

am11 · 2025-07-14T18:44:44Z

@gwr has confirmed that ad-hoc tests are passing. Full lib tests will be run once we get the bootstrapped SDK ready (which is getting closer). So this looks good. 👍

@janvorli, @jkotas, this is ready for review. PTAL.

gwr · 2025-07-25T17:08:35Z

Any more feedback? Thanks. (bump?)

eng/Subsets.props

jkotas · 2025-09-03T01:24:33Z

src/installer/pkg/projects/netcoreappRIDs.props


    <!-- The following RIDs are not officically supported and are not
         built during official builds, however we wish to include them
         in our runtime.json to enable others to provide them.  -->


Where is the runtime.json that this talks about going to show up?

I am wondering whether this is still needed.

Where is the runtime.json that this talks about going to show up?

runtime/src/installer/pkg/projects/Directory.Build.props

Lines 80 to 86 in b3de022



<BuildRID Include="@(UnofficialBuildRID)" Exclude="@(_buildingOnRID)">

<ExcludeFromPlatformManifest>true</ExcludeFromPlatformManifest>

</BuildRID>

<BuildRID Include="@(_buildingOnRID)"/>

<RestoreBuildRID Include="@(BuildRID)" Exclude="@(UnofficialBuildRID)" />

How does BuildRID flow to runtime.json? What's the path to the runtime.json file? Is it shipping anywhere?

I think it would be best to separate the infra changes from the System.Diagnostics.Process changes. PRs that combine multiple completely unrelated fixes are hard to land.

FWIW, this code is here for ages. PR isn't inventing anything new.

Yes, I know it has been there for ages. I am trying to understand what it is still used for and whether it is still needed. I am not able to able to find runtime.json that the comment talks about.

src/libraries/Common/src/Interop/SunOS/procfs/Interop.ProcFs.Definitions.cs

src/native/libs/System.Native/pal_io.h

src/libraries/Common/src/Interop/SunOS/procfs/Interop.ProcFs.Definitions.cs

gwr · 2025-09-07T14:11:09Z

After the recent merge of main into the PR branch, I'm getting a build error I don't understand:


$ export CMAKE_MAKE_PROGRAM=/usr/local/bin/cmake
$ export ROOTFS_DIR=/crossrootfs/x64
$ ./build.sh clr+libs+libs.tests -c Debug -cross -os illumos -gcc --bootstrap
... 
  [ 50%] Building CXX object vm/CMakeFiles/cee_dac.dir/readytorunstandalonemethodmetadata.cpp.o
  /home/gwr/dotnet/runtime/src/coreclr/vm/methodtable.cpp: In static member function 'static MethodTable::MethodData* MethodTable::GetMethodDataHelper(MethodTable*, MethodTable*, MethodDataComputeOptions)':
  /home/gwr/dotnet/runtime/src/coreclr/vm/methodtable.cpp:7130:52: error: 'static void MethodTable::MethodData::operator delete(void*)' called on pointer returned from a mismatched allocation function [-Werror=mismatched-new-delete]
   7130 |             pData = new MethodDataInterface(pMTDecl);
        |                                                    ^
  /home/gwr/dotnet/runtime/src/coreclr/vm/methodtable.cpp:7130:52: note: returned from 'void* operator new(std::size_t)'
   7130 |             pData = new MethodDataInterface(pMTDecl);
        |                                                    ^
  [ 50%] Building CXX object vm/wks/CMakeFiles/cee_wks_core.dir/__/onstackreplacement.cpp.o
  cc1plus: all warnings being treated as errors
  make[3]: *** [vm/wks/CMakeFiles/cee_wks_core.dir/build.make:973: vm/wks/CMakeFiles/cee_wks_core.dir/__/methodtable.cpp.o] Error 1
  make[3]: *** Waiting for unfinished jobs....
...
  [ 52%] Linking CXX static library libcee_dac.a
  [ 52%] Built target cee_dac
  make[1]: *** [CMakeFiles/Makefile2:1944: CMakeFiles/runtime.dir/rule] Error 2
  make: *** [Makefile:228: runtime] Error 2
  ~/dotnet/runtime/src/coreclr
  Failed to build "CoreCLR component".
/home/gwr/dotnet/runtime/src/coreclr/runtime.proj(116,5): error MSB3073: The command ""/home/gwr/dotnet/runtime/src/coreclr/build-runtime.sh" -x64 -debug gcc -cross -os illumos -targetrid illumos-x64 -cmakeargs "-DCLR_DOTNET_RID=illumos-x64" -cmakeargs "-DCLR_DOTNET_HOST_PATH=/home/gwr/dotnet/runtime/.dotnet/dotnet" -cmakeargs "-DCDAC_BUILD_TOOL_BINARY_PATH=/home/gwr/dotnet/runtime/artifacts/bin/coreclr/illumos.x64.Debug/cdac-build-tool/cdac-build-tool.dll" -component runtime" exited with code 2.

Build FAILED.

Help? (resolved below. See #119447)

jkotas · 2025-09-07T14:52:43Z

error: 'static void MethodTable::MethodData::operator delete(void*)' called on pointer returned from a mismatched allocation function

Looks related to #119112

gwr · 2025-09-07T18:08:42Z

Looks related to #119112

Thanks. I picked up changes through Aug 30 (including that fix) but I'm still getting the error. That business with destructors is a bit tricky for me to figure out.

gwr · 2025-09-07T21:35:13Z

Looks related to #119112

This seems to let it build. Does this look right?

diff --git a/src/coreclr/vm/methodtable.cpp b/src/coreclr/vm/methodtable.cpp
index 6389c40c855..167f2a614c5 100644
--- a/src/coreclr/vm/methodtable.cpp
+++ b/src/coreclr/vm/methodtable.cpp
@@ -7127,7 +7127,7 @@ MethodTable::MethodData *MethodTable::GetMethodDataHelper(MethodTable *pMTDecl,
     // If we get here, there are no entries in the cache.
     if (pMTDecl == pMTImpl) {
         if (pMTDecl->IsInterface()) {
-            pData = new MethodDataInterface(pMTDecl);
+            pData = new ({pMTDecl}) MethodDataInterface(pMTDecl);
         }
         else {
             MethodDataHolder h(FindParentMethodDataHelper(pMTDecl));

I went ahead and created a PR with this: #119447

gwr · 2025-09-09T02:23:01Z

I'm catching up with the merge first, and then updating as requested in reviews.

gwr · 2025-09-09T02:32:28Z

Base now on main as of Aug 30. to pick up #119112

Read /proc (binary) psinfo for System.Diagnostic.Process using src/native/libs/System.Native C functions. Add native/libs/System.Native/pal_io.c etc. Add src/libraries/Common/src/Interop/SunOS/procfs Add src/libraries/System.Diagnostics.Process Co-authored-by: Austin Wise <AustinWise@gmail.com> Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>

gwr · 2025-09-09T02:47:06Z

Pushed new version with changes requested by reviewers,
and drop commits that will be in other PRs.

Note that to build this, three other changes are requied:

Workaround Bootstrap is failing on platform without AOT support #116929
Fix illumos compile errors in coreclr/tools/superpmi/mcs/verbmerge.cpp Fix illumos compile errors in coreclr/tools/superpmi/mcs/verbmerge.cpp #117464
Fix compile error in coreclr/vm/methodtable.cpp GetMethodDataHelper Fix compile error in coreclr/vm/methodtable.cpp GetMethodDataHelper #119447

In case anyone wants to build this, here's a branch with all four changes:
https://github.com/gwr/dotnet-runtime/commits/illumos6

jkotas · 2025-09-09T03:16:54Z

src/libraries/Common/src/Interop/SunOS/procfs/Interop.ProcFs.Definitions.cs

+            internal int Tid;
+            internal int Priority;
+            internal int NiceVal;
+            internal char StatusCode;


This is uint8_t in the unmanaged view. It should be byte here.

(char is 16-bit in C#, so there is a mismatch between the managed and unmanaged definitions.)

jkotas · 2025-09-09T03:25:28Z

src/libraries/System.Diagnostics.Process/src/System.Diagnostics.Process.csproj

+    <Compile Include="$(CommonPath)Interop\SunOS\procfs\Interop.ProcFs.Definitions.cs"
+             Link="Common\Interop\SunOS\procfs\Interop.ProcFs.Definitions.cs" />


Suggested change

<Compile Include="$(CommonPath)Interop\SunOS\procfs\Interop.ProcFs.Definitions.cs"

Link="Common\Interop\SunOS\procfs\Interop.ProcFs.Definitions.cs" />

<Compile Include="$(CommonPath)Interop\SunOS\procfs\Interop.ProcFs.cs"

Link="Common\Interop\SunOS\procfs\Interop.ProcFs.cs" />

Nit: There is no other *.Definitions.cs file under libraries. To follow the repo conventions, this should be Interop.ProcFs.cs or Interop.ProcFs.Common.cs - if there is anything left in this file after incorporating the other feedback.

jkotas · 2025-09-09T03:30:06Z

src/libraries/Common/src/Interop/SunOS/procfs/Interop.ProcFs.Definitions.cs

+        // Output type for TryGetProcessInfoById()
+        // Keep in sync with pal_io.h ProcessInfo
+        [StructLayout(LayoutKind.Sequential)]
+        internal struct ProcessInfo


It would make more sense for this to be in Interop.ProcFs.TryGetProcessInfoById.cs. We typically place the structures that support the internal API in the same file as the API, so that one can include the least amount of interop goo a lot of unnecessary goo to use the internal API.

jkotas · 2025-09-09T03:31:23Z

src/libraries/Common/src/Interop/SunOS/procfs/Interop.ProcFs.Definitions.cs

+            internal char StatusCode;
+        }
+
+        internal static string GetInfoFilePathForProcess(int pid) =>


This looks unused

jkotas · 2025-09-09T03:31:58Z

src/libraries/Common/src/Interop/SunOS/procfs/Interop.ProcFs.Definitions.cs

+        internal static string GetLwpDirForProcess(int pid) =>
+            $"{RootPath}{(uint)pid}{lwpDirName}";
+
+        internal static string GetInfoFilePathForThread(int pid, int tid) =>


This looks unused

jkotas · 2025-09-09T18:13:58Z

src/libraries/System.Diagnostics.Process/src/System/Diagnostics/ProcessThread.SunOS.cs

+            }
+            return iinfo;
+        }
+


Suggested change

jkotas · 2025-09-09T18:17:48Z

src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.SunOS.cs

+            Interop.procfs.ProcessInfo iinfo;
+            if (!Interop.procfs.TryGetProcessInfoById(_processId, out iinfo))


Suggested change

Interop.procfs.ProcessInfo iinfo;

if (!Interop.procfs.TryGetProcessInfoById(_processId, out iinfo))

Interop.procfs.ProcessInfo processInfo;

if (!Interop.procfs.TryGetProcessInfoById(_processId, out processInfo))

Does the i prefix in iinfo mean something?

jkotas · 2025-09-09T18:18:27Z

src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.SunOS.cs

+{
+    public partial class Process : IDisposable
+    {
+


Suggested change

jkotas · 2025-09-09T18:22:40Z

src/libraries/Common/src/Interop/SunOS/procfs/Interop.ProcFs.TryGetProcessInfoById.cs

+        /// <param name="pid">PID of the process to read status info for.</param>
+        /// <param name="processInfo">The pointer to ProcessInfo instance.</param>
+        /// <returns>
+        /// true if the process status was read; otherwise, false.


The method implementation throws on errors. It never returns false. Should it be void GetProcessInfoById instead? (dtto for other similar Try methods)

jkotas · 2025-09-09T18:24:51Z

src/libraries/Common/src/Interop/SunOS/procfs/Interop.ProcFs.TryGetProcessInfoById.cs

+            ProcessInfo info = default;
+            if (ReadProcessInfo(pid, &info, null, 0) < 0)
+            {
+                Interop.ErrorInfo errorInfo = Sys.GetLastErrorInfo();
+                throw new IOException(errorInfo.GetErrorMessage(), errorInfo.RawErrno);
+            }
+            processInfo = info;


Suggested change

ProcessInfo info = default;

if (ReadProcessInfo(pid, &info, null, 0) < 0)

{

Interop.ErrorInfo errorInfo = Sys.GetLastErrorInfo();

throw new IOException(errorInfo.GetErrorMessage(), errorInfo.RawErrno);

}

processInfo = info;

fixed (ProcessInfo* pProcessInfo = &processInfo)

{

if (ReadProcessInfo(pid, pProcessInfo, null, 0) < 0)

{

Interop.ErrorInfo errorInfo = Sys.GetLastErrorInfo();

throw new IOException(errorInfo.GetErrorMessage(), errorInfo.RawErrno);

}

}

ProcessInfo is a structure with non-trivial size. It would be better to pin it to avoid unnecessary copying. (dtto for other similar places)

ghost added the area-System.Diagnostics.Process label Jul 24, 2024

dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Jul 24, 2024

gwr mentioned this pull request Jul 24, 2024

Tracking issue for illumos and Solaris x86-64 port work #34944

Open

19 tasks