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

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

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.

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.

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)
 

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