Add loongarch64 support

[zhaixiaojuan]

The LoongArch architecture (LoongArch) is an Instruction Set
Architecture (ISA) that has a Reduced Instruction Set Computer (RISC)
style.
The documents are on：
https://loongson.github.io/LoongArch-Documentation/README-EN.html
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Amanieu (or someone else) soon.

Please see the contribution instructions for more information.

[Amanieu]

LGTM! Once you have added a loongarch target in rustc, you'll want to add it to ci/build.sh under RUST_LINUX_NO_CORE_TARGETS so that the target is tested in libc CI.

[Amanieu]

Did you forget to commit loongarch64/mod.rs?

[Amanieu]

LGTM. The CI changes should be added after the target has been added to rustc.

[Amanieu]

This should be removed: it will cause CI to fail since the target hasn't been added to rustc yet.

[zhaixiaojuan]

a. I have removed loongarch64-unknown-linux-gnu in ci/build.rs.
b. Added loongarch64 support in libc-test and completed the test locally. But for libc-test is it better to submit a PR separately?
See the test result: zhaixiaojuan@467c34c
c. Adjusted the loongarch64/mod.rs file according to the test of libc-test.

[Amanieu]

You should add it in a separate PR once loongarch64-unknown-linux-gnu is available on nightly rust.

[Amanieu]

@bors r+

[bors]

📌 Commit 467c34c has been approved by Amanieu

[bors]

⌛ Testing commit 467c34c with merge d747e7d...

[bors]

☀️ Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: Amanieu
Pushing d747e7d to master...

[xen0n]

Holy moly, I didn't even know the existence of Loongson's porting efforts until I was kindly pointed to rust-lang/rust#96971, by @xry111, knowing that such effort cannot begin before the kernel/libc ABI freeze... next time surely CC me ;-)

[xry111]

Some questions:

1. LoongArch doesn't have any big endian variant and I think it will never have one (it's now 2022 :). So should we remove the code about big endian or keep it for some reason I don't know?
2. LoongArch won't have some syscalls, for example newfstatat. But the reference to newfstatat exists in our code. Should we remove it or keep it for some reason?

[xen0n]

Some questions:

1. LoongArch doesn't have any big endian variant and I think it will never have one (it's now 2022 :).  So should we remove the code about big endian or keep it for some reason I don't know?

Definitely. It's unlikely LoongArch would ever become bi-endian, byteswapping is so cheap with dedicated revb instructions, that full-scale big-endian operation just isn't worth it. Plus bitfield semantics and aliasing between integer widths (think about how offsets are the same for a i64 field in a struct, no matter how you access it, whether as i8 or i16 or i32; in BE the offsets are different which is mildly annoying.)

2. LoongArch won't have some syscalls, for example [newfstatat](https://sourceware.org/pipermail/libc-alpha/2022-June/139257.html).  But the reference to newfstatat exists in our code.  Should we remove it or keep it for some reason?

Definitely too, we don't want to ever see fstat and newfstatat in the new world. (@zhaixiaojuan: This is precisely why people usually avoid starting any porting work before the ABI is officially frozen; if you ever followed the conversation at LKML you'd removed the fstat bits. We're in no hurry.)