[PATCH v7 00/13] GLIBC LoongArch PATCHES

Tue Jul 26 12:35:23 GMT 2022

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:
>>>> <snip>
>>>> 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