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

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

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. :( ..

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.

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

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

Thanks,
Yanzhang

> -----Original Message-----
> From: Palmer Dabbelt <palmer@dabbelt.com>
> Sent: Wednesday, September 20, 2023 9:37 PM
> To: adhemerval.zanella@linaro.org
> Cc: Wang, Yanzhang <yanzhang.wang@intel.com>; DJ Delorie <dj@redhat.com>;
> Darius Rad <darius@bluespec.com>; libc-alpha@sourceware.org
> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> 
> On Mon, 11 Sep 2023 09:17:22 PDT (-0700), adhemerval.zanella@linaro.org
> wrote:
> >
> >
> > On 09/09/23 00:30, Palmer Dabbelt wrote:
> >> On Fri, 08 Sep 2023 20:17:16 PDT (-0700), yanzhang.wang@intel.com wrote:
> >>> I took some time to test the master with binfmt_misc and qemu system
> mode.
> >>> Both of them can't match the requirements (<= 6 failures).
> >>>
> >>> - most of cases with binfmt_misc fail with abort.
> >>
> >> QEMU user mode isn't a valid test suite target for glibc, there's lots
> of failures due to the emulation.  I know it's confusing that riscv-gnu-
> toolchain uses it, that come up when support was added.
> >>
> >>> - most of cases with qemu system fail with timed out.
> >>
> >> You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.
> >>
> >>> And also tested with my risc-v board and still fails 70+ cases and
> >>> most of them are math accuracy issue.
> >>
> >> Which board are you running on?
> >>
> >>> So Adhemerval, do you know how to setup the environment to reproduce
> >>> the <= 6 failures ? Maybe I lost some important steps. Thanks very
> much :).
> >>
> >> +DJ and Darius, who usually report test results.  They've probably got
> the best idea of how to set things up, but I don't remember this requiring
> anything fancy.
> >
> > For the specific support of static-pie, I expect that qemu-system or
> > even qemu-user would be a feasible testing platform.  You might need
> > some adjustment if the platform implements some math code in assembly,
> > but if you filter out the expected failures it should be doable to
> > check the feature is working as intended.
> 
> It looks like the HW in question likely has some issues in the FPU, see
> <https://github.com/revyos/revyos/issues/17>.  We'll have to figure
> something out (maybe just disable FP until userspace has ack'd that it
> understands the errata?), but for now it's probably best to just test on
> QEMU.
> 
> > However it is hard to filter out if you just specify the number of
> > failure before/after without breaking down which tests has failed and
> > why (Was is due timeout due emulation? Was it due missing
> > libstdc++.so/libgcc_s.so support? Was is math failure due wrong
> emulation?).
> >
> >>
> >>>
> >>> Thanks,
> >>> Yanzhang
> >>>
> >>>> -----Original Message-----
> >>>> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> >>>> Sent: Tuesday, August 15, 2023 7:46 PM
> >>>> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
> >>>> <palmer@dabbelt.com>; libc-alpha@sourceware.org
> >>>> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> >>>>
> >>>>
> >>>>
> >>>> On 13/08/23 09:20, Wang, Yanzhang via Libc-alpha wrote:
> >>>> > Hi Palmer,
> >>>> >
> >>>> > I have tested the commit(542b110585) with this patch. The results
> >>>> > like below,
> >>>> >
> >>>> > Summary of test results:
> >>>> >     189 FAIL
> >>>> >    4328 PASS
> >>>> >     101 UNSUPPORTED
> >>>> >      16 XFAIL
> >>>> >       2 XPASS
> >>>> >
> >>>> > And the commit(542b110585)'s results like below,
> >>>> >
> >>>> > Summary of test results:
> >>>> >     189 FAIL
> >>>> >    4326 PASS
> >>>> >     101 UNSUPPORTED
> >>>> >      16 XFAIL
> >>>> >       2 XPASS
> >>>> >
> >>>> > The binutils's commit is 2db20b97f1d and gcc's commit is bf36656a14a.
> >>>> >
> >>>> > I use the command make check-glibc-linux in riscv-gnu-toolchain.
> >>>> > Not sure is that acceptable.
> >>>>
> >>>> The riscv reports for 2.38 release [1] list at maximum of 6 FAIL
> >>>> for all the ABI variants.  The 189 failures you are reporting means
> >>>> that your environment is either missing some setup (for instance,
> >>>> copying the libgcc_s.so and libstd++.so on the build folder so C++
> >>>> and tests that require pthread_cancel or backtrace works correctly)
> >>>> or it is not properly configured.
> >>>>
> >>>> Please sort this out first, since with that amount of failures is
> >>>> not straightforward to check whether static-pie is really working as
> intended.
> >>>