From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id EBA3B385801B for ; Tue, 26 Jul 2022 12:35:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EBA3B385801B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from [10.20.4.187] (unknown [10.20.4.187]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9BxQ9CL399itbs5AA--.17720S3; Tue, 26 Jul 2022 20:35:23 +0800 (CST) Subject: Re: [PATCH v7 00/13] GLIBC LoongArch PATCHES From: caiyinyu To: Adhemerval Zanella Netto , WANG Xuerui , libc-alpha@sourceware.org, joseph_myers@mentor.com, carlos@redhat.com References: <20220719012056.1461897-1-caiyinyu@loongson.cn> Message-ID: <36bc5e0f-165f-d535-529d-4bc9d6de3aca@loongson.cn> Date: Tue, 26 Jul 2022 20:35:23 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID: AQAAf9BxQ9CL399itbs5AA--.17720S3 X-Coremail-Antispam: 1UD129KBjvJXoWxKryrKF4rWw15KrW5AryrZwb_yoWxKr1rpr 9aqFn5GFWUXFZaya42q3WUXFW0yFZxKF15JryDXF97Cw1kZwnFqrWaqryjgF9rJw4kKF1Y vry8G3W7uF90vaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMc vjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487MxkI ecxEwVCm-wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F4 0E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1l IxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxV AFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUgg _TUUUUU X-CM-SenderInfo: 5fdl5xhq1xqz5rrqw2lrqou0/ X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2022 12:35:34 -0000 Also, once you add the loongarch entry on release wiki [2], please the configure options use to state ifunc needs to be explicit disabled. --------- I have created an account (caiyinyu@loongson.cn) on glibc wiki and we need to participate in the wiki to edit loongarch parts. 在 2022/7/25 下午10:14, caiyinyu 写道: >> I guess a v8 is better because the 17th patch (NEWS) needs a rebase >> anyway.  But let's wait for Adhemerval's suggestion... > > It is up to your, if you are ok with my fixed branch I can install > otherwise > you send a v8. > > -------------------- > > I checked and I'm ok with the fixed branch. > > Waiting for other suggestions. > > Thanks. > > > > 在 2022/7/25 下午9:27, Adhemerval Zanella Netto 写道: >> >> On 24/07/22 06:49, WANG Xuerui wrote: >>> Hi, >>> >>> On 7/19/22 09:20, caiyinyu wrote: >>>> >>>> 6. Test result: all passed (ifunc disable). >>>> >>>> Test with: >>>>     Linux-5.19-rc4, Binutils-2.38, and GCC-12.1. >>>>     glibc: >>>> https://github.com/loongson/glibc/tree/loongarch_2_36_upstream_v7 >>>> >>>> Result (ifunc disable): >>>> XPASS: conform/UNIX98/ndbm.h/linknamespace >>>> XPASS: conform/XOPEN2K/ndbm.h/linknamespace >>>> XPASS: conform/XOPEN2K8/ndbm.h/linknamespace >>>> XPASS: conform/XPG42/ndbm.h/linknamespace >>>> UNSUPPORTED: crypt/cert >>>> UNSUPPORTED: elf/tst-env-setuid >>>> UNSUPPORTED: elf/tst-env-setuid-tunables >>>> XPASS: elf/tst-protected1a >>>> XPASS: elf/tst-protected1b >>>> UNSUPPORTED: elf/tst-valgrind-smoke >>>> UNSUPPORTED: misc/tst-adjtimex >>>> UNSUPPORTED: misc/tst-clock_adjtime >>>> UNSUPPORTED: misc/tst-ntp_adjtime >>>> UNSUPPORTED: misc/tst-pkey >>>> UNSUPPORTED: misc/tst-rseq >>>> UNSUPPORTED: misc/tst-rseq-disable >>>> UNSUPPORTED: nptl/test-cond-printers >>>> UNSUPPORTED: nptl/test-condattr-printers >>>> UNSUPPORTED: nptl/test-mutex-printers >>>> UNSUPPORTED: nptl/test-mutexattr-printers >>>> UNSUPPORTED: nptl/test-rwlock-printers >>>> UNSUPPORTED: nptl/test-rwlockattr-printers >>>> UNSUPPORTED: nptl/tst-pthread-gdb-attach >>>> UNSUPPORTED: nptl/tst-pthread-gdb-attach-static >>>> UNSUPPORTED: nptl/tst-rseq-nptl >>>> UNSUPPORTED: stdlib/tst-secure-getenv >>>> UNSUPPORTED: time/tst-clock_settime >>>> UNSUPPORTED: time/tst-settimeofday >>>> Summary of test results: >>>>      4535 PASS >>>>        22 UNSUPPORTED >>>>        12 XFAIL >>>>         6 XPASS >>> Thanks for your effort these days. I ran the test on Gentoo and this >>> is what I have found out: >>> >>> UNSUPPORTED: crypt/cert >>> FAIL: elf/check-abi-libc >>> FAIL: elf/ifuncmain1 >>> FAIL: elf/ifuncmain1pic >>> FAIL: elf/ifuncmain1pie >>> FAIL: elf/ifuncmain1staticpic >>> FAIL: elf/ifuncmain1staticpie >>> FAIL: elf/ifuncmain1vis >>> FAIL: elf/ifuncmain1vispic >>> FAIL: elf/ifuncmain1vispie >>> FAIL: elf/ifuncmain2 >>> FAIL: elf/ifuncmain2pic >>> FAIL: elf/ifuncmain3 >>> FAIL: elf/ifuncmain4 >>> FAIL: elf/ifuncmain5staticpic >>> FAIL: elf/ifuncmain6pie >>> FAIL: elf/ifuncmain7 >>> FAIL: elf/ifuncmain7pic >>> FAIL: elf/ifuncmain7pie >>> FAIL: elf/ifuncmain9 >>> FAIL: elf/ifuncmain9pic >>> FAIL: elf/ifuncmain9pie >>> UNSUPPORTED: elf/tst-env-setuid >>> UNSUPPORTED: elf/tst-env-setuid-tunables >>> FAIL: elf/tst-glibc-hwcaps-prepend-cache >>> FAIL: elf/tst-ifunc-textrel >>> FAIL: elf/tst-ldconfig-ld_so_conf-update >>> XPASS: elf/tst-protected1a >>> XPASS: elf/tst-protected1b >>> UNSUPPORTED: elf/tst-valgrind-smoke >>> FAIL: malloc/tst-free-errno-malloc-hugetlb1 >>> UNSUPPORTED: misc/tst-adjtimex >>> UNSUPPORTED: misc/tst-clock_adjtime >>> UNSUPPORTED: misc/tst-ntp_adjtime >>> UNSUPPORTED: misc/tst-pkey >>> UNSUPPORTED: misc/tst-rseq >>> UNSUPPORTED: misc/tst-rseq-disable >>> FAIL: nptl/tst-pthread-gdb-attach >>> FAIL: nptl/tst-pthread-gdb-attach-static >>> UNSUPPORTED: nptl/tst-rseq-nptl >>> FAIL: nss/tst-nss-files-hosts-long >>> UNSUPPORTED: resolv/tst-resolv-ai_idn >>> UNSUPPORTED: resolv/tst-resolv-ai_idn-latin1 >>> UNSUPPORTED: stdlib/tst-secure-getenv >>> UNSUPPORTED: time/tst-clock_settime >>> UNSUPPORTED: time/tst-settimeofday >>> >>> Of these, the ifunc failures are "expected" by you, the >>> elf/check-abi-libc diff is trivial (maybe you just didn't rebase as >>> frequently): >>> >>> --- ../sysdeps/unix/sysv/linux/loongarch/lp64/libc.abilist >>> 2022-07-23 14:45:57.490029442 +0800 >>> +++ /home/xenon/src/glibc/build/libc.symlist    2022-07-24 >>> 13:44:10.416642655 +0800 >>> @@ -496 +496 @@ GLIBC_2.36 _mcount F >>> -GLIBC_2.36 _nl_default_dirname D 0x12 >>> +GLIBC_2.36 _nl_default_dirname D 0x17 >>> @@ -541,0 +542,3 @@ GLIBC_2.36 alphasort64 F >>> +GLIBC_2.36 arc4random F >>> +GLIBC_2.36 arc4random_buf F >>> +GLIBC_2.36 arc4random_uniform F >>> >>> The others may need some love. Of course they're possibly because of >>> my particular environment (Gentoo is a little bit different than >>> "ordinary" distros like Debian/Fedora, and I already have to symlink >>> the libgcc_s.so and libstdc++.so to pass the nptl tests at all). >> The 'elf/tst-glibc-hwcaps-prepend-cache' and >> 'elf/tst-ldconfig-ld_so_conf-update', >> might worth to take a look, although they are not arch-specific and I >> think it is >> more related to the test environment. >> >> Also, once you add the loongarch entry on release wiki [2], please >> the configure >> options use to state ifunc needs to be explicit disabled. >> >>> Coming to code quality, there are obviously warts present, like the >>> lingering uses of the name "x" for $r21 and apparent lack of >>> assembly pseudo-insn sugar usages (e.g. no "move a, b" but always >>> "or a, b, zero"; the code must be directly descended from an >>> extremely early time when the assembler didn't have such support), >>> but at this point these cosmetic concerns are better fixed after >>> 2.36 to minimize churn prior to release. At a quick glance the ABI >>> is looking good. (There is a certain "__x" in bits/setjmp.h meant to >>> refer to r21, but __jmp_buf is not public API so I think we're safe >>> here.) >>> >> I agree that cosmetic issues should not interfere with loongarch64 >> addition, we >> can backport if required (although for such changes I also do not see >> much >> point). >> >> I have create a branch which I think it is suitable for inclusion [1], I >> have fixed the ABI issue due arc4random addition and some style issues >> (trailing lines) that were triggering our pre-commit hooks.. >> >>> I guess a v8 is better because the 17th patch (NEWS) needs a rebase >>> anyway.  But let's wait for Adhemerval's suggestion... >> It is up to your, if you are ok with my fixed branch I can install >> otherwise >> you send a v8. >> >> [1] >> https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/loongarch64 >> [2] https://sourceware.org/glibc/wiki/Release/2.36