[PATCH] RISC-V: Enable static-pie.
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Tue Oct 17 13:42:10 GMT 2023
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
More information about the Libc-alpha
mailing list