[LoongArch64] add build-config for LoongArch64. #8271

shushanhf · 2021-12-17T03:53:43Z

To double check:

The right tests are in and and the right validation has happened. Guidance: https://github.com/dotnet/core-eng/tree/master/Documentation/Validation

jkotas

LGTM.

@am11 Could you please take a look as well?

am11 · 2021-12-17T05:29:50Z

eng/common/cross/toolchain.cmake

@@ -36,6 +36,9 @@ elseif(TARGET_ARCH_NAME STREQUAL "arm64")
  if("$ENV{__DistroRid}" MATCHES "tizen.*")
    set(TIZEN_TOOLCHAIN "aarch64-tizen-linux-gnu/9.2.0")
  endif()
+elseif(TARGET_ARCH_NAME STREQUAL "loongarch64")


@shushanhf, updating this file alone is not enough as we will also need setup bits in build-rootfs.sh.
The build-rootf.sh is then used in https://github.com/dotnet/dotnet-buildtools-prereqs-docker/ repo, to produce the cross-build docker container for various platforms/architectures (e.g. ubuntu-18.04-cross-arm-alpine-xxx, ubuntu-18.04-cross-illumos-xxx etc. full list of tags). This makes it easier for anyone (including runtime CI pipelines) to consume the container and build product.

Are all packages listed in build-rootfs.sh script available on loongarch64, and which distro will you be targeting? I am asking because for Debian riscv64 architecture, I am still waiting on a patch from lldb team for System-V support (meanwhile I unset lldb like s390x below). Other than that, riscv64 is still in Debian ports so I had to modify this script a little to add sid support (dotnet/runtime@main...am11:feature/riscv-rootfs, still WIP as I'm also waiting for llvm 13.0.1, which has a default fix for .NET ML dependencies, so I can remove the TODO).
For local testing:

# sudo is only required for debbotstrap command, other platforms like alpine and illumos don't require root sudo eng/common/cross/build-rootfs.sh riscv64 sudo eng/common/cross/build-rootfs.sh freebsd # etc.

then in runtime repo, pass cross arg: ROOTFS_DIR=$(pwd)/.tools/rootfs/loongarch64 ./build.sh clr -cross -arch loongarch64 ... (in the docker container, that ROOTFS_DIR will have a set path /crossrootfs/loongarch64)

@shushanhf, updating this file alone is not enough as we will also need setup bits in build-rootfs.sh.

Thanks!
I will commit LoongArch64 to this.
https://hub.fastgit.org/shushanhf/arcade/blob/main/eng/common/cross/build-rootfs.sh

Are all packages listed in build-rootfs.sh script available on loongarch64, and which distro will you be targeting? I am asking because for Debian riscv64 architecture, I am still waiting on a patch from lldb team for System-V support (meanwhile I unset lldb like s390x below). Other than that, riscv64 is still in Debian ports so I had to modify this script a little to add sid support (dotnet/runtime@main...am11:feature/riscv-rootfs, still WIP as I'm also waiting for llvm 13.0.1, which has a default fix for .NET ML dependencies, so I can remove the TODO). For local testing:

We can supply ubuntu20.04. Now we are preparing qemu supporting LoongArch64.

# sudo is only required for debbotstrap command, other platforms like alpine and illumos don't require root sudo eng/common/cross/build-rootfs.sh riscv64 sudo eng/common/cross/build-rootfs.sh freebsd # etc.

then in runtime repo, pass cross arg: ROOTFS_DIR=$(pwd)/.tools/rootfs/loongarch64 ./build.sh clr -cross -arch loongarch64 ... (in the docker container, that ROOTFS_DIR will have a set path /crossrootfs/loongarch64)

That means we have to supply a LoongArch64 rootfs tar-file and including a cross-compiler ?

That means we have to supply a LoongArch64 rootfs tar-file and including a cross-compiler ?

If we are on loongarch64 host, and building for loongarch64, then toolchain.cmake is not involved. I imagine it is your case, where you are locally using the baremetal loongarch64 machine. This cmake script is only involved when we cross compile the .NET runtime or SDK (e.g. in the CI where we only have x64 or arm64 host, so arm32, x86, s380x etc. binaries are cross-compiled then sent to remote machines with real hardware for testing). See https://github.com/dotnet/runtime/blob/b338078/eng/native/gen-buildsys.sh#L82 (the outer condition is if [[ "$CROSSCOMPILE" == "1" ]]).

build-rootfs.sh is a helper script which integrates seamlessly with rest of the engineering stack. If we can arrange the debootstrap setup for loongarch64 (e.g. I found some discussion here: https://gitlab.summer-ospp.ac.cn/summer2021/210080299/-/blob/main/week12_report.md), it would be nice, because after that we can request for a docker container (e.g. a PR like dotnet/dotnet-buildtools-prereqs-docker#324 with addition of qemu-loongarch64 package). With that docker container it will make things easier for everyone to build runtime for loongarch64 on any system where docker is installed.

Long story short, it is not required to have a cross compiler right now (it can be added later), and then we can update both toolchain.cmake and build-rootfs.sh together (as there might be other changes needed in toolchain.cmake, right now we can't test it or tell for sure).

That means we have to supply a LoongArch64 rootfs tar-file and including a cross-compiler ?

If we are on loongarch64 host, and building for loongarch64, then toolchain.cmake is not involved. I imagine it is your case, where you are locally using the baremetal loongarch64 machine. This cmake script is only involved when we cross compile the .NET runtime or SDK (e.g. in the CI where we only have x64 or arm64 host, so arm32, x86, s380x etc. binaries are cross-compiled then sent to remote machines with real hardware for testing). See https://github.com/dotnet/runtime/blob/b338078/eng/native/gen-buildsys.sh#L82 (the outer condition is if [[ "$CROSSCOMPILE" == "1" ]]).

Yes, now we just test and run all dotnet on our LoongArch64-linux machine.

build-rootfs.sh is a helper script which integrates seamlessly with rest of the engineering stack. If we can arrange the debootstrap setup for loongarch64 (e.g. I found some discussion here: https://gitlab.summer-ospp.ac.cn/summer2021/210080299/-/blob/main/week12_report.md), it would be nice, because after that we can request for a docker container (e.g. a PR like dotnet/dotnet-buildtools-prereqs-docker#324 with addition of qemu-loongarch64 package). With that docker container it will make things easier for everyone to build runtime for loongarch64 on any system where docker is installer.

Long story short, it is not required to have a cross compiler right now (it can be added later), and then we can update both toolchain.cmake and build-rootfs.sh together (as there might be other changes needed in toolchain.cmake, right now we can't test it or tell for sure).

Thanks.
Here is a link page for qemu and toolchain, https://github.com/loongson/build-tools.

If we are on loongarch64 host, and building for loongarch64, then toolchain.cmake is not involved. I imagine it is your case, where you are locally using the baremetal loongarch64 machine. This cmake script is only involved when we cross compile the .NET runtime or SDK (e.g. in the CI where we only have x64 or arm64 host, so arm32, x86, s380x etc. binaries are cross-compiled then sent to remote machines with real hardware for testing).

By the way, do you need the real hardware of LoongArch64 for testing ?
If you need, we can supply the LoongArch64 machine for you.

By the way, do you need the real hardware of LoongArch64 for testing ?

I do know that question for not for me, but why do not ask. Can I get free treat? At least I can guarantee that I make NativeAOT work on this platform.

Long story short, it is not required to have a cross compiler right now (it can be added later), and then we can update both toolchain.cmake and build-rootfs.sh together

Agree. @shushanhf Could you please revert changes in toolchain.cmake so that we can get the rest of the changes in this PR merged?

@am11 If incremental infrastructure changes are ok, what do you feel about following future plan for cross-compile. That should be treated as stop-gap measurements in case debootstrap MR would take long time to be merged or other organizational issues arise.

Right now GCC and CLang cannot produce LoongArch64 execuables from released version and work just starting. so debootstrap is not enough (isn't it?). That mean that temporary cross compilation can be achieved via other means, like @shushanhf suggests above:

That means we have to supply a LoongArch64 rootfs tar-file and including a cross-compiler ?

Is this alternative viable for the future?

By the way, do you need the real hardware of LoongArch64 for testing ?

I do know that question for not for me, but why do not ask. Can I get free treat? At least I can guarantee that I make NativeAOT work on this platform.

Yes, complimentary a desktop host.

Long story short, it is not required to have a cross compiler right now (it can be added later), and then we can update both toolchain.cmake and build-rootfs.sh together

Agree. @shushanhf Could you please revert changes in toolchain.cmake so that we can get the rest of the changes in this PR merged?

Ok, I will do it right now.

@am11 If incremental infrastructure changes are ok, what do you feel about following future plan for cross-compile. That should be treated as stop-gap measurements in case debootstrap MR would take long time to be merged or other organizational issues arise.

Right now GCC and CLang cannot produce LoongArch64 execuables from released version and work just starting. so debootstrap is not enough (isn't it?). That mean that temporary cross compilation can be achieved via other means, like @shushanhf suggests above:

That means we have to supply a LoongArch64 rootfs tar-file and including a cross-compiler ?

Is this alternative viable for the future?

I had prepared a cross-comiler on x64-linux for LoongArch64.
If you needed, I can give you.

Although our company had finished all the comilers (gcc、clang、.NET、JVM、browser ...) and some tools liking docker, it still needs a little time to be accepted by the upstream.

There is another way for cross-compiling.

We can supply a docker image and a docker source suppling the related softwares before you get them from the upstream, liking getting the docker images about LoongArch64 from the docker-hub.

am11 · 2021-12-20T12:41:04Z

LGTM, thank you.

shushanhf · 2021-12-20T12:47:27Z

LGTM, thank you.

Thanks for your review～

[LoongArch64] add build-config for LoongArch64.

c297282

shushanhf mentioned this pull request Dec 17, 2021

[LoongArch64] add all the coreclr-build-config files dotnet/runtime#62889

Merged

jkotas approved these changes Dec 17, 2021

View reviewed changes

am11 reviewed Dec 17, 2021

View reviewed changes

am11 mentioned this pull request Dec 17, 2021

[LoongArch64] add the coreclr/pal directory dotnet/runtime#62887

Merged

[LoongArch64] revert the eng/common/cross/toolchain.cmake.

a38f81a

jkotas merged commit dd29c2f into dotnet:main Dec 20, 2021

danmoseley mentioned this pull request Feb 7, 2022

Add RuntimeConfiguration.NotRelease danmoseley/arcade#1

Closed

1 task

gbalykov mentioned this pull request Jun 25, 2024

[RiscV64] add build-config for RiscV64 #14895

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[LoongArch64] add build-config for LoongArch64. #8271

[LoongArch64] add build-config for LoongArch64. #8271

shushanhf commented Dec 17, 2021

jkotas left a comment

am11 Dec 17, 2021 •

edited

Loading

shushanhf Dec 17, 2021 •

edited

Loading

am11 Dec 17, 2021 •

edited

Loading

shushanhf Dec 17, 2021

shushanhf Dec 17, 2021

kant2002 Dec 20, 2021

jkotas Dec 20, 2021

kant2002 Dec 20, 2021

shushanhf Dec 20, 2021 •

edited

Loading

shushanhf Dec 20, 2021

am11 commented Dec 20, 2021

shushanhf commented Dec 20, 2021

[LoongArch64] add build-config for LoongArch64. #8271

[LoongArch64] add build-config for LoongArch64. #8271

Conversation

shushanhf commented Dec 17, 2021

To double check:

jkotas left a comment

Choose a reason for hiding this comment

am11 Dec 17, 2021 • edited Loading

Choose a reason for hiding this comment

shushanhf Dec 17, 2021 • edited Loading

Choose a reason for hiding this comment

am11 Dec 17, 2021 • edited Loading

Choose a reason for hiding this comment

shushanhf Dec 17, 2021

Choose a reason for hiding this comment

shushanhf Dec 17, 2021

Choose a reason for hiding this comment

kant2002 Dec 20, 2021

Choose a reason for hiding this comment

jkotas Dec 20, 2021

Choose a reason for hiding this comment

kant2002 Dec 20, 2021

Choose a reason for hiding this comment

shushanhf Dec 20, 2021 • edited Loading

Choose a reason for hiding this comment

shushanhf Dec 20, 2021

Choose a reason for hiding this comment

am11 commented Dec 20, 2021

shushanhf commented Dec 20, 2021

am11 Dec 17, 2021 •

edited

Loading

shushanhf Dec 17, 2021 •

edited

Loading

am11 Dec 17, 2021 •

edited

Loading

shushanhf Dec 20, 2021 •

edited

Loading