public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
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" <libc-alpha@sourceware.org>
Subject: Re: [PATCH] RISC-V: Enable static-pie.
Date: Tue, 17 Oct 2023 10:42:10 -0300	[thread overview]
Message-ID: <d3ed4903-3a1a-490d-804e-bbc885e31e20@linaro.org> (raw)
In-Reply-To: <IA1PR11MB6466C05B8BB4DD6C7061D151F2F8A@IA1PR11MB6466.namprd11.prod.outlook.com>



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

  parent reply	other threads:[~2023-10-17 13:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10 23:33 yanzhang.wang
2023-08-11  1:57 ` Palmer Dabbelt
2023-08-13 12:20   ` Wang, Yanzhang
2023-08-15 11:46     ` Adhemerval Zanella Netto
2023-09-09  3:17       ` Wang, Yanzhang
2023-09-09  3:30         ` Palmer Dabbelt
2023-09-09  6:54           ` Wang, Yanzhang
2023-09-11 14:14             ` Palmer Dabbelt
2023-09-11 13:34           ` Darius Rad
2023-09-11 17:28             ` DJ Delorie
2023-09-11 16:17           ` Adhemerval Zanella Netto
2023-09-20 13:36             ` Palmer Dabbelt
2023-09-21 13:47               ` Wang, Yanzhang
2023-10-17  8:28                 ` Wang, Yanzhang
2023-10-17 13:42                 ` Adhemerval Zanella Netto [this message]
2023-10-24  5:59                   ` Wang, Yanzhang
2023-10-24 11:39                     ` Adhemerval Zanella Netto
2023-10-26  3:30                       ` Wang, Yanzhang
2023-08-14 13:12 ` Carlos O'Donell
2023-08-15  1:48   ` Wang, Yanzhang
2023-08-15  1:44 ` [PATCH v2] " yanzhang.wang
2023-12-17 13:16   ` Wang, Yanzhang
2023-12-19 17:44   ` Adhemerval Zanella Netto
2024-01-02 11:02     ` Wang, Yanzhang
2024-01-02 10:54 ` [PATCH v3] " yanzhang.wang
2024-01-02 18:30   ` Adhemerval Zanella Netto
2024-01-17 12:23   ` Andreas Schwab
2024-01-29 12:46   ` Andreas Schwab
2024-02-01 12:39     ` Wang, Yanzhang
2024-02-01 12:53       ` Andreas Schwab
2024-05-21 11:13   ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d3ed4903-3a1a-490d-804e-bbc885e31e20@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=darius@bluespec.com \
    --cc=dj@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=palmer@dabbelt.com \
    --cc=yanzhang.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).