[PATCH] RISC-V: Enable static-pie.
Wang, Yanzhang
yanzhang.wang@intel.com
Tue Oct 17 08:28:44 GMT 2023
Hi,
Is there any further comments about this patch?
I have pushed another v2 version someday ago, and there's no conflict now.
https://patchwork.sourceware.org/project/glibc/patch/20230815014434.1902446-1-yanzhang.wang@intel.com/
Thanks,
Yanzhang
> -----Original Message-----
> From: Wang, Yanzhang
> Sent: Thursday, September 21, 2023 9:48 PM
> To: Palmer Dabbelt <palmer@dabbelt.com>; adhemerval.zanella@linaro.org
> Cc: DJ Delorie <dj@redhat.com>; Darius Rad <darius@bluespec.com>; libc-
> alpha@sourceware.org
> Subject: RE: [PATCH] RISC-V: Enable static-pie.
>
> 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.
> > >>>
More information about the Libc-alpha
mailing list