@benoithudson, could you have a look?
@bimajatiwijaya, could you check whether this branch works for you?

The only thing I have is an old Raspberry Pi and a few phones, I just used godbolt to get the binaries. That's why I'd like people that had problems to test this branch ;)

Codecov Report

Merging #887 into master will increase coverage by 0.08%.
The diff coverage is 93.33%.

@@            Coverage Diff             @@
##           master     #887      +/-   ##
==========================================
+ Coverage   76.86%   76.94%   +0.08%     
==========================================
  Files          64       64              
  Lines        5909     5939      +30     
  Branches      974      974              
==========================================
+ Hits         4542     4570      +28     
- Misses       1040     1042       +2     
  Partials      327      327

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2bc514f...d834b65. Read the comment docs.

Codecov Report

Merging #887 into master will decrease coverage by 13.94%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master     #887       +/-   ##
===========================================
- Coverage   76.86%   62.92%   -13.95%     
===========================================
  Files          64        1       -63     
  Lines        5909      294     -5615     
  Branches      974        0      -974     
===========================================
- Hits         4542      185     -4357     
+ Misses       1040      109      -931     
+ Partials      327        0      -327

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2bc514f...d834b65. Read the comment docs.

Ummm, I think it seems that it would better if we create a dynamic library and use P/Invoke to get a function address rather than making some hard codes like these?

That would complicate the build process quite a lot though. I'd really like to get to a single arch independent assembly in the future that can just be compiled using dotnet cli without any additional params.

But at first, you always need to build a sample binary and disassembly to get codes depend the system.
If you worry about the build process, why not just upload that prebuilt binary to repository, so that users would not need any compile.
What if we need to compatible systems like these:

How complicated would typemanager.cs be......
Well, for now, this is not a big problem because there are only two dummy functions.

The trick is that it's straight binary, so you only need one of these per cpu arch, not per os (no ELF vs PE distinction, no libc linking etc). Be my guest in providing a reasonable alternative.

Oh, it is. I almost neglect it.

That would complicate the build process quite a lot though. I'd really like to get to a single arch independent assembly in the future that can just be compiled using dotnet cli without any additional params.

Me too, which is why my patch that introduced this code was discovering the platform at runtime rather than with ifdefs.

If there's some rainy days I'll see about converting more of the code. Eliminating the MONO_LINUX and MONO_OSX defines would be nice; UCS as well.

By the way, the implementation for Runtime.InitializePlatformData just have some limitations.
The platform.py would import subprocess, but not all release binaries have it, I encounter it before and use ifdef skiped, any good suggestion?

Probably inline the two functions. IIRC one of the calls has a CPython component, the other I didn't track down.

We're getting pretty far off the original topic, I wonder if comments on this PR are the best way to gather our thoughts?