Re: [PATCH] RISC-V: Enable static-pie.

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 24/10/23 02:59, Wang, Yanzhang wrote:
> Hi Adhemerval,
> 
> Thanks for your comments and the two categories cases are all figured out.
> 
> For the timed out cases, I increased the TIMEOUTFACTOR to 300 and finally passed.
> The 100 seems not working very well.

Excellent.

> 
> For the case elf/tst-tls-allocation-failure-static-patched, the root cause is it
> does not run with test-wrapper. I use cross-test-ssh.sh to run tests on the board.
> If no test-wrapper, it will run on my local. That's why exec format error.

Alright, so I don't have any further remarks for this patch.

> 
> I need to apply another patch below. Is it acceptable or I need to run the full
> test directly on board?
> 
> diff --git a/elf/Makefile b/elf/Makefile
> index 9176cbf1e3..1065b5c123 100644
> --- a/elf/Makefile
> +++ b/elf/Makefile
> @@ -2979,7 +2979,7 @@ $(objpfx)tst-tls-allocation-failure-static-patched: \
> 
>  $(objpfx)tst-tls-allocation-failure-static-patched.out: \
>    $(objpfx)tst-tls-allocation-failure-static-patched
> -       $< > $@ 2>&1; echo "status: $$?" >> $@
> +       $(test-wrapper) $< > $@ 2>&1; echo "status: $$?" >> $@
>         grep -q '^Fatal glibc error: Cannot allocate TLS block$$' $@ \
>           && grep -q '^status: 127$$' $@; \
>           $(evaluate-test)

This would require to be in a different path, could you send it as well?

>  
> 
>> -----Original Message-----
>> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
>> Sent: Tuesday, October 17, 2023 9:42 PM
>> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
>> <palmer@dabbelt.com>
>> Cc: DJ Delorie <dj@redhat.com>; Darius Rad <darius@bluespec.com>; libc-
>> alpha@sourceware.org
>> Subject: Re: [PATCH] RISC-V: Enable static-pie.
>>
>>
>>
>> On 21/09/23 10:47, Wang, Yanzhang wrote:
>>> Thanks for all your comments, Palmer, DJ, Dairus and Adhemerval.
>>> Your suggestions are so helpful to me.
>>>
>>> Yes. I also found this issue on GitHub too and the math failures
>>> didn't appear with QEMU system. So it's definitely a hardware bug.
>>>
>>> And I found the root cause of almost of the other failures. It's
>>> because I use sshfs not nfs. :( ..
>>
>> I don't have access to RISCV hardware, but we can use the 2.38 release [1]
>> as the baseline [1].
>>
>>>
>>> Even though I set a larger TIMEOUTFACTOR as you said, there're still
>>> some timeout failures like below. And seems the timeout is not stable.
>>> Sometimes, nptl/tst-stack4 can pass on lp4a and sometimes not.
>>
>> The tst-stack4 was a long standing issue that should be fixed on master
>> [2].
>>
>>>
>>>   master with qemu-system       master on lp4a                static-
>> pie patch on lp4a
>>>  ----------------------------- ----------------------------- ----------
>> -------------------
>>>   resolv/tst-resolv-res_ninit   resolv/tst-resolv-res_ninit
>> resolv/tst-resolv-res_ninit
>>>   nptl/tst-stack4               nptl/tst-stack4
>> iconvdata/tst-loading
>>>   libio/tst-fopenloc            libio/tst-fopenloc
>> localedata/tst-leaks
>>>   iconvdata/tst-loading         iconvdata/tst-loading
>> malloc/tst-dynarray-fail
>>>   localedata/tst-leaks          localedata/tst-leaks
>> posix/tst-fnmatch
>>>   malloc/tst-dynarray-fail      malloc/tst-dynarray-fail
>>>   posix/tst-glob-tilde          posix/tst-glob-tilde
>>>   posix/tst-fnmatch             posix/tst-fnmatch
>>
>>
>> For static-pie I would focus on the *static* tests and check for any
>> regressions.
>> On the above, all are dynamic and most likely the timeout you have found
>> are due a low TIMEOUTFACTOR value.
>>
>> You can check by testing each one individually:
>>
>> $ TIMEOUTFACTOR=100 make test t=<test> # for instance, posix/tst-fnmatch
>>
>>>
>>> For the FAIL tests, it's like below. The math failures are filtered
>>> out on lp4a and not appear on qemu-system.
>>>
>>>   master with qemu-system                         master on lp4a
>> static-pie patch on lp4a
>>>  ----------------------------------------------- ----------------------
>> ------------------------- -----------------------------------------------
>>>   resolv/mtrace-tst-resolv-res_ninit              resolv/mtrace-tst-
>> resolv-res_ninit              resolv/mtrace-tst-resolv-res_ninit
>>>   nptl/tst-cancel21-static                        libio/tst-fopenloc-
>> mem                          elf/tst-tls-allocation-failure-static-
>> patched
>>>   libio/tst-fopenloc-mem                          libio/tst-fopenloc-
>> cmp                          elf/tst-rtld-list-diagnostics
>>>   libio/tst-fopenloc-cmp                          elf/tst-tls-
>> allocation-failure-static-patched   elf/tst-sprof-basic
>>>   elf/tst-tls-allocation-failure-static-patched   elf/tst-rtld-list-
>> diagnostics                   iconvdata/mtrace-tst-loading
>>>   elf/tst-rtld-list-diagnostics                   elf/tst-sprof-basic
>> localedata/mtrace-tst-leaks
>>>   elf/tst-sprof-basic                             iconvdata/mtrace-tst-
>> loading                    malloc/tst-dynarray-fail-mem
>>>   iconvdata/mtrace-tst-loading                    localedata/mtrace-
>> tst-leaks                     posix/tst-fnmatch-mem
>>>   localedata/mtrace-tst-leaks                     malloc/tst-dynarray-
>> fail-mem
>>>   malloc/tst-dynarray-fail-mem                    posix/tst-glob-tilde-
>> mem
>>>   posix/tst-glob-tilde-mem                        posix/tst-fnmatch-mem
>>>   posix/tst-fnmatch-mem
>>>   posix/globtest
>>
>> The elf/tst-sprof-basic seems to be a know issue based on 2.38 release
>> wiki, and most of them seems also for related to the low TIMEOUTFACTOR.
>>
>>>
>>> Take master on lp4a as an example,
>>>
>>> - elf/tst-rtld-list-diagnostics, due to missing abnf module
>>> - elf/tst-sprof-basic, successfully print hello world but return
>>> status is 1, still unknown root cause
>>> - elf/tst-tls-allocation-failure-static-patched, exec format error,
>>> still unknown root cause
>>
>> This seems to be a real regression, and I think you should sort this out
>> before the patch is installed (I see no failure on qemu-user on master).
>> The exec format error seems to come from kernel, due the execve failure;
>> and might a corrupted binary.
>>
>>> - the others are memory not freed
>>>
>>> The difference between qemu-system and lp4a for master is the two
>>> cases,
>>>
>>> - nptl/tst-cancel21-static, it said sa_flags = SA_ONSTACK and haven't
>> investigated.
>>
>> This might a unrelated issue [3], either in compiler optimization or due
>> the the long-standing BZ#12683 issue.
>>
>>> - posix/globtest, because my qemu-system has a different user name.
>>>
>>> The XFAILs and XPASSes are the same on all platforms and all branches.
>>> So not list here.
>>>
>>> I use the commit 4be913652ca115160bae1daf560170ef8b112ccb of master
>> branch.
>>>
>>> So is this the expected test result? Or is there still any case not
>> correct FAIL or PASS?
>>
>> I think the output look pretty ok, the only issue being the elf/tst-tls-
>> allocation-failure-static failure.
>>
>>
>> [1] https://sourceware.org/glibc/wiki/Release/2.38#RISC-
>> V_.28rv64imac.2Flp64.29
>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=19329
>> [3] https://sourceware.org/pipermail/libc-alpha/2019-
>> September/106641.html