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

["Wang, Yanzhang" <yanzhang.wang@intel.com>]

Of cause. I have sent it just now and cc you too.

> -----Original Message-----
> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> Sent: Tuesday, October 24, 2023 7:39 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 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