[0/14,LoongArch] Add LoongArch GLIBC port support

  Hi all:

This is a series of patches to support the new LoongArch architecture.

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

ISA manual is on:
LoongArch Reference Manual Volume 1: Basic Architecture
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html

The ELF ABI Document is on:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

The GCC code based on GCC trunk:
https://github.com/loongson/gcc/tree/loongarch_upstream
We will send those patches for review soon.

The BINUTILS code based on BINUTILS trunk:
https://github.com/loongson/binutils-gdb/tree/loongarch/upstream_v6_a1d65b3
The BINUTILS patch is under review:
https://sourceware.org/pipermail/binutils/2021-August/117697.html

The GLIBC code based on GLIBC trunk:
https://github.com/loongson/glibc/commits/loongarch_2_34_for_upstream

The kernel patch is under review:
https://lwn.net/Articles/861951/

The 32-bit toolchain does not work, we just keep the relevant code.
Please skip it while reviewing, we will fix it in the future.

Here is the patch list:
[PATCH  1/14] [LoongArch] Add relocations and ELF flags to elf.h
[PATCH  2/14] [LoongArch] ABI Implementation
[PATCH  3/14] [LoongArch] Thread Local Storage Support
[PATCH  4/14] [LoongArch] Generic math.h and soft fp Routines
[PATCH  5/14] [LoongArch] Atomic and Locking Routines
[PATCH  6/14] [LoongArch] Linux Syscall Interface
[PATCH  7/14] [LoongArch] Linux ABI
[PATCH  8/14] [LoongArch] Linux Startup and Dynamic Loading Code
[PATCH  9/14] [LoongArch] Add ABI Lists
[PATCH 10/14] [LoongArch] Build Infastructure
[PATCH 11/14] [LoongArch] Hard Float Support
[PATCH 12/14] [LoongArch] Add optimized string functions
[PATCH 13/14] [LoongArch] Add assembly optimized sinf cosf functions
[PATCH 14/14] [LoongArch] Add optimized memcpy set move

Thanks.


















Thanks.
  

On Thu, 19 Aug 2021, Paul Hua via Libc-alpha wrote:

> This is a series of patches to support the new LoongArch architecture.

Please see <https://sourceware.org/glibc/wiki/NewPorts> for more 
information for new port contributors and port maintainers.  There are 
various things listed there that will need addressing for the next 
revision of this port.  Here are some general observations, mostly based 
on points from that wiki page, but you should go through everything on 
that page carefully rather than assuming everything relevant from that 
page is mentioned in this message.

Please note that a new revision of the port should be self-contained (all 
information about the port as a whole, or about an individual patch, 
that's included in one of the messages in this revision of the port, needs 
to be included in the corresponding message for the new revision as well, 
if still applicable to that revision).  Descriptions of what changed 
relative to previous revisions can be included after a "---" line (i.e. 
follow "git am" conventions for what is intended to be part of a commit 
message versus other information not intended to be part of a commit 
message).


1. Is there ABI documentation for the function-calling ABI?  The ELF ABI 
document you link to says essentially nothing about that.


2. Please provide details of the test results for the port with the glibc 
testsuite and the binutils / GCC / Linux kernel ports as submitted 
upstream (the exact versions of those components proposed for upstream, 
not some other version).  You might need to work around some of the issues 
currently present building glibc with GCC mainline; if so, please state 
the exact patches you are using for that workaround on top of the proposed 
port version (you might need to use 
<https://sourceware.org/pipermail/libc-alpha/2021-August/130244.html>, for 
example).  It's required that the compilation parts of the testsuite must 
have fully clean results.  For any test failures in the rest of the 
testsuite, make the .out and .test-result files available, along with any 
analysis you have done of why those tests are failing.


3. I see there's an upstream submission (not yet committed upstream) of 
QEMU support for LoongArch, could you describe the status of that?  (See 
"There is no requirement for a CPU simulator (free software, e.g. QEMU, or 
otherwise) to be available, but if one is available, it is useful to 
mention in the summary message (along with any information on available OS 
etc. that might help people set up an environment for testing things about 
the port)." on the NewPorts page.)


4. What ABIs are supported for the port?  You mention 32-bit doesn't work 
(so it would be best to remove that code until it's ready), so only 64-bit 
ABIs are supported.  Is a soft-float ABI supported, or only hard-float?  
You have __loongarch_soft_float or __loongarch_hard_float conditionals in 
some places, but other things suggest only hard float is supported (the 
lack of any with_fp_cond definition in your preconfigure fragment, in 
particular).  Apart from conventional 32-bit and 64-bit ABIs, there's the 
question of whether you have or intend to have an ILP32 ABI that uses 
64-bit registers and the 64-bit instruction set (like x32 for x86_64); 
there's no need to have such an ABI, but if you do plan to have one, you 
need to be very careful about what you mean when you say "32-bit" or 
"64-bit", to make it clear whether such an ILP32 ABI is included or not.


5. There needs to be at least one entry added to build-many-glibcs.py for 
each ABI supported by the port.


6. You're making local changes to config.sub and config.guess.  Don't do 
that; the latest versions from config.git should be imported instead, with 
no local changes, outside of the patch series adding the port.


7. This patch series is missing NEWS and README updates.


8. We don't use "Contributed by" any more in new source files.  You can 
put such information in the NEWS entry for the addition of the port, and 
in contrib.texi (the latter listing relevant individuals, not companies), 
instead.


9. Note that new source files should have a one-line description above the 
copyright notice.


10. Note the need for a manual/math.texi update in the list of 
configurations supporting _Float128.


11. Florian has already noted that GLIBC_2.35 should be the minimum ABI 
version for the port.  This has other implications beyond the DEFAULT 
setting in shlib-versions.  You're adding some entries to 
sysdeps/unix/sysv/linux/loongarch/Versions with old symbol versions; those 
should not be present (some of the GLIBC_2.0 entries are for libgcc 
functions only relevant for extremely old glibc ports).  If you need any 
Versions entries at all, they should be either GLIBC_PRIVATE or 
GLIBC_2.35, and you should be able to give an explicit justification for 
why such an entry is needed (i.e. the function would not be exported at 
all without the entry, and either is part of the architecture-independent 
glibc API, or is needed as an architecture-specific function or a 
GLIBC_PRIVATE function).


12. For each ABI supported by the port (see point 4 above) you need a 
unique dynamic linker name (not used by any existing ABI listed at 
<https://sourceware.org/glibc/wiki/ABIList>; probably mentioning the 
architecture name somewhere in the dynamic linker name), as specified with 
ld= in shlib-versions.  You have an ldd_rewrite_script setting that only 
makes sense with such names (and only makes sense when multiple ABIs are 
supported in the same root filesystem, see 
<https://sourceware.org/legacy-ml/libc-alpha/2018-01/msg00008.html> for 
more details of what's needed for such support), but I don't see anything 
to actually implement such names.  Note the need for the dynamic linker 
names to be consistent in GCC and glibc.


13. arch_minimum_kernel should be set to 10.0.0 until the actual upstream 
kernel version that gets the port is known, and then to the actual 
upstream version (so 5.14.0 or later).  Accordingly, kernel-features.h 
should not have any "before 4.20" conditionals in it (so you don't need an 
architecture-specific kernel-features.h at all).


14. Regarding the optimized functions in patches 12 to 14, see the last 
point on the NewPorts page regarding considering carefully (possibly with 
benchmarking) whether such functions are actually beneficial compared to 
the current generic C versions - and, if beneficial compared to the 
current generic C versions, whether helping to get the improved generic 
functions linked from that page into glibc would avoid the need for some 
or all of the architecture-specific implementations.