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.

* 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

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-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 <[email protected]> Co-authored-by: Adeel Mujahid <[email protected]>

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

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

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

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

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

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?

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

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)

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

Let ThreadInfo.StatusCode be uint16_t (C# char) move structs where they're used Remove Interop.ProcFs.Definitions.cs Let SDP compose /proc strings Use fixed in getinfo funcs kill unused, fix nits

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