Message ID | CAKjxQH=AQwWcEWFBpEg=qiJNxp2ceP_WJYQ-1iNm=3_S2Sg5ow@mail.gmail.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 121D63897054 for <patchwork@sourceware.org>; Thu, 19 Aug 2021 03:29:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 121D63897054 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629343785; bh=d3P/hLcajnASe4QxXL2ccbTOdU3KPmQOq9VOEBPfSOE=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=C/sm0g2cQqBbcKJduqKOzMoHb4BH5qhYB8ogqeIL612368c8e3nHoY8cXtvjZJ15E 40Bw/ZNS/QA/UeKI15WxgatWX6kd1BL4cD2yH9a92/698TIlzkxCvevLie0g49XBPO koPmtLGAl2omt81ZdK16ZnIOWaxPzEdaxWtl6e7E= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by sourceware.org (Postfix) with ESMTPS id BAA3B38515F6 for <libc-alpha@sourceware.org>; Thu, 19 Aug 2021 03:29:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BAA3B38515F6 Received: by mail-yb1-xb36.google.com with SMTP id a126so9562515ybg.6 for <libc-alpha@sourceware.org>; Wed, 18 Aug 2021 20:29:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=d3P/hLcajnASe4QxXL2ccbTOdU3KPmQOq9VOEBPfSOE=; b=dMvC9lOWIz/HqqkIu6i7oXgnTNlNNqghz7kBWCj9sr7sc1cYHn5uTaUm872K45OARn n/TaavnAtXvd88RhefcGF+fnKrnkksyQO7HbyB78yYL/3vEPvPYMB+M3L8zcxrv5BiOF BjsbRpV+40gSLInVTBP4yRXZwyR65/KgkkSRzVcHVVoVDiaa9E2CCN1pWIkw4PvvvpBp Toyh0WVgsglAkZsFvcYYeVJoUnNoeCtrDGTZ2erpClMGvdjULpLRIfAjtTwgaziBHCr5 uW+mROXW00OVQtAwuF/q8NVbnI3Q+qeZHdH1HgQDohoiIRAWJCZIId58OpQHUyTaIgnp ARYg== X-Gm-Message-State: AOAM531Lu95J2DMsdSopvsf8QNeT5jOK4z2vYfSrxzLiuG+uAhlldkzK vy7W+hEDiS7Hwo6JpO3lDSNJplwXVXcXgyxKGE+Pe3Kmly0vUkAe X-Google-Smtp-Source: ABdhPJwqFe52sELwZHafc4RVTro9ahS4dGlg2Z/A9uBFWgAfhP1pkEF6gZ2n+WH0Il0KNa7kVoHpXQWomCn7LmG00Kk= X-Received: by 2002:a25:aaa4:: with SMTP id t33mr15694152ybi.256.1629343753133; Wed, 18 Aug 2021 20:29:13 -0700 (PDT) MIME-Version: 1.0 Date: Thu, 19 Aug 2021 11:29:01 +0800 Message-ID: <CAKjxQH=AQwWcEWFBpEg=qiJNxp2ceP_WJYQ-1iNm=3_S2Sg5ow@mail.gmail.com> Subject: [PATCH 0/14][LoongArch] Add LoongArch GLIBC port support To: libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Paul Hua via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Paul Hua <paul.hua.gm@gmail.com> Cc: Xu Chenghua <xuchenghua@loongson.cn>, huangpei@loongson.cn, caiyinyu@loongson.cn Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Add LoongArch GLIBC port support
|
|
Message
Paul Hua
Aug. 19, 2021, 3:29 a.m. UTC
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.
Comments
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.