RISC-V NativeAOT port

[am11]

This is to track the progress of nativeaot port on riscv64 architecture.

WIP initial translation (based on @sunlijun-610's LA64 port):
main...am11:runtime:feature/nativeaot/riscv64-port

[am11]

cc @dotnet/samsung, @filipnavara

If someone wants take over, let me know. I can also give ssh access to riscv computer (bianbu OS, Debian derivative) if needed for testing. 👍

[am11]

Some assertions are failing at build-time in AsmOffset* and llvm-libunwind due to the sizes of various structs. llvm-libunwind is getting 96 bytes size difference in UnwindCursor<A, R> vs. unw_cursor_t which is a mystery. See the TODO added in src/native/external/llvm-libunwind/src/UnwindCursor.hpp, that template function is there temporarily to print the sizes on stderr during the build.

Also, I've used the register names we have in coreclr/pal. Some of them might not be needed, but I'm not sure since llvm-libunwind uses different names X1,X2,X3.. while coreclr/pal is using T1,T2,T3.. so I used the latter and handled the mapping in src/coreclr/nativeaot/Runtime/unix/UnwindHelpers.cpp.

[am11]

Applied changes from #106225.

FWIW, this is my workflow:

# on macOS arm64
$ cd runtime
$ docker run -e ROOTFS_DIR=/crossrootfs/riscv64 -v$(pwd):/runtime -w /runtime --rm \
    --platform linux/arm64 -it ubuntu

$ eng/common/native/install-dependencies.sh 
$ apt install -y debootstrap
$ eng/common/cross/build-rootfs.sh riscv64 noble --skipunmount --rootfsdir /crossrootfs/riscv64
$ src/coreclr/build-runtime.sh -cross -riscv64

# once nativeaot runtime ^ starts building in silo, we can try a full build
# rm -rf artifacts
# ./build.sh clr+libs+packs -cross --arch riscv64

currently it is not getting too far 😅

...
[ 45%] Building CXX object nativeaot/Runtime/Full/CMakeFiles/Runtime.WorkstationGC.dir/__/__/__/gc/unix/events.cpp.o
[ 45%] Building CXX object classlibnative/bcltype/CMakeFiles/bcltype.dir/system.cpp.o
In file included from /runtime/src/coreclr/nativeaot/Runtime/AsmOffsetsVerify.cpp:43:
In file included from /runtime/src/coreclr/nativeaot/Runtime/AsmOffsets.h:79:
/runtime/src/coreclr/nativeaot/Runtime/riscv64/AsmOffsetsCpu.h:10:1: error: static assertion failed due to requirement '(sizeof(ExInfo) == 2120) || (sizeof(ExInfo) > 2120)': Bad asm size for 'ExInfo', the actual size is smaller than 0x848.
   10 | PLAT_ASM_SIZEOF(848, ExInfo)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/runtime/src/coreclr/nativeaot/Runtime/AsmOffsetsVerify.cpp:36:19: note: expanded from macro 'PLAT_ASM_SIZEOF'
   36 |     static_assert((sizeof(cls) == 0x##size) || (sizeof(cls) > 0x##size), "Bad asm size for '" #cls "', the actual size is smaller than 0x" #size "."); \
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /runtime/src/coreclr/nativeaot/Runtime/AsmOffsetsVerify.cpp:43:
In file included from /runtime/src/coreclr/nativeaot/Runtime/AsmOffsets.h:79:
/runtime/src/coreclr/nativeaot/Runtime/riscv64/AsmOffsetsCpu.h:15:1: error: static assertion failed due to requirement '(__builtin_offsetof(ExInfo, m_passNumber) == 28) || (__builtin_offsetof(ExInfo, m_passNumber) > 28)': Bad asm offset for 'ExInfo.m_passNumber', the actual offset is smaller than 0x1C.
   15 | PLAT_ASM_OFFSET(1C, ExInfo, m_passNumber)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/runtime/src/coreclr/nativeaot/Runtime/AsmOffsetsVerify.cpp:32:19: note: expanded from macro 'PLAT_ASM_OFFSET'
   32 |     static_assert((offsetof(cls, member) == 0x##offset) || (offsetof(cls, member) > 0x##offset), "Bad asm offset for '" #cls "." #member "', the actual offset is smaller than 0x" #offset "."); \
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

[filipnavara]

I tried to compile your branch and I ended up pretty much at the same spot. Currently away from computer, but this should be easy to fix…

[am11]

@filipnavara, have you had a chance to check out the assertion failures? No rush—just wondering if there are any blockers or details we need to sort out. Thanks! 👍

[filipnavara]

Unfortunately no, still tackling some things for .NET 9 release and few other hack projects that I want to get done for the .NET 10 timeframe. I hope to eventually look into it but it’s currently not a priority, sorry.

[am11]

Ok, no worries, I'll also take a look when I get a chance. Was hoping to get some feedback from @viewizard et al. on register naming since it's not immediately clear to which convention is preferred at present day (and given llvm-libunwind has its own which is obviously different than HP-libunwind, coreclr VM and PAL). 😅