Message ID | 20160720.153931.575029361394679476.davem@davemloft.net |
---|---|
State | New, archived |
Headers |
Received: (qmail 108807 invoked by alias); 20 Jul 2016 22:39:36 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 108794 invoked by uid 89); 20 Jul 2016 22:39:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=sk:carlos, carlos@redhat.com, sk:carlos@, carlosredhatcom X-HELO: shards.monkeyblade.net Date: Wed, 20 Jul 2016 15:39:31 -0700 (PDT) Message-Id: <20160720.153931.575029361394679476.davem@davemloft.net> To: carlos@redhat.com Cc: libc-alpha@sourceware.org, rth@redhat.com, samuel.thibault@ens-lyon.org, hjl.tools@gmail.com, vapier@gentoo.org, schwab@suse.de, chunglin_tang@mentor.com, adhemerval.zanella@linaro.org Subject: Re: Testing glibc 2.24 on remaining machines. From: David Miller <davem@davemloft.net> In-Reply-To: <521d3f7a-6375-11c7-5987-ad2f0f1ab290@redhat.com> References: <521d3f7a-6375-11c7-5987-ad2f0f1ab290@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit |
Commit Message
David Miller
July 20, 2016, 10:39 p.m. UTC
From: Carlos O'Donell <carlos@redhat.com> Date: Sat, 16 Jul 2016 14:11:27 -0400 > Are you able to do the sparc and sparc64 testing? I did v9 sparc and sparc64 runs and they mostly look fine. I had to apply this (year old) patch to fix the wcsmbs comparison test case. The memory compared must be aligned suitably for the type being used, otherwise we get SIGBUS on platforms like sparc:
Comments
On Wed, 2016-07-20 at 15:39 -0700, David Miller wrote: > From: Carlos O'Donell <carlos@redhat.com> > Date: Sat, 16 Jul 2016 14:11:27 -0400 > > > Are you able to do the sparc and sparc64 testing? > > I did v9 sparc and sparc64 runs and they mostly look fine. Great, thanks. What do we do with pre-v9 sparc though? I believe pthreads barriers don't work on it currently, and the new condvar and rwlock implementaitons that we'll hopefully switch to in the next cycle also wouldn't work on pre-v9 sparc. Do we want to: (1) not further support pre-v9 sparc? (2) not further support all of pthreads on pre-v9 sparc (and potentially other things in glibc that use rwlocks, IIRC we don't use condvars internally)? (3) build something that emulates full C11 atomics, either backed by locks in the synchronization data structure or a process-global lock array (though we'd have to adapt the current condvar because there's no space for an extra lock there)? We could also continue to adapt each synchronization data structure specially to pre-v9 sparc, but I don't think this is good enough in terms of maintainability. Personally, I also don't have time to work on (3).
From: Torvald Riegel <triegel@redhat.com> Date: Thu, 21 Jul 2016 13:32:48 +0200 > (3) build something that emulates full C11 atomics, either backed by > locks in the synchronization data structure or a process-global lock > array (though we'd have to adapt the current condvar because there's no > space for an extra lock there)? Nothing done completely inside of glibc will support signals properly. Even the current locking in glibc deadlocks in several testcases because of this problem. Like some other architectures in the same situation have done, we would need something in the kernel to implement locking properly and in a signal safe way. And it's really hard to justify all of that work.
On Thu, 21 Jul 2016, David Miller wrote: > Nothing done completely inside of glibc will support signals properly. > Even the current locking in glibc deadlocks in several testcases > because of this problem. > > Like some other architectures in the same situation have done, we > would need something in the kernel to implement locking properly > and in a signal safe way. > > And it's really hard to justify all of that work. Then should we follow option (1) not further support pre-v9 sparc? If so, much the same approach should be followed as for i386: make configure give an error when the compiler is configured for pre-v9; merge sysdeps directories so there are no longer separate sparcv8 and sparcv9 subdirectories but sparc/sparc32 assumes v9; remove obsolete preprocessor conditionals such as in kernel-features.h.
On 07/21/2016 10:06 PM, Joseph Myers wrote: > Then should we follow option (1) not further support pre-v9 sparc? > If so, much the same approach should be followed as for i386: make configure > give an error when the compiler is configured for pre-v9; merge sysdeps > directories so there are no longer separate sparcv8 and sparcv9 > subdirectories but sparc/sparc32 assumes v9; remove obsolete preprocessor > conditionals such as in kernel-features.h. Possibly we should retain a place for Leon3, which is mostly v8 but adds the casa instruction and the ability to use #ASI_USER_DATA from userspace. r~
On 22 Jul 2016 09:37, Richard Henderson wrote: > On 07/21/2016 10:06 PM, Joseph Myers wrote: > > Then should we follow option (1) not further support pre-v9 sparc? > > If so, much the same approach should be followed as for i386: make configure > > give an error when the compiler is configured for pre-v9; merge sysdeps > > directories so there are no longer separate sparcv8 and sparcv9 > > subdirectories but sparc/sparc32 assumes v9; remove obsolete preprocessor > > conditionals such as in kernel-features.h. > > Possibly we should retain a place for Leon3, which is mostly v8 but adds the > casa instruction and the ability to use #ASI_USER_DATA from userspace. Gentoo def sees leon users. off the top of my head, that's the only v8 we still really see. -mike
On 07/20/2016 06:39 PM, David Miller wrote: > From: Carlos O'Donell <carlos@redhat.com> > Date: Sat, 16 Jul 2016 14:11:27 -0400 > >> Are you able to do the sparc and sparc64 testing? > > I did v9 sparc and sparc64 runs and they mostly look fine. > > I had to apply this (year old) patch to fix the wcsmbs comparison test > case. The memory compared must be aligned suitably for the type > being used, otherwise we get SIGBUS on platforms like sparc: > > diff --git a/string/test-strncmp.c b/string/test-strncmp.c > index 8c0a331..d392248 100644 > --- a/string/test-strncmp.c > +++ b/string/test-strncmp.c > @@ -156,6 +156,9 @@ do_test_limit (size_t align1, size_t align2, size_t len, size_t n, int max_char, > size_t i, align_n; > CHAR *s1, *s2; > > + align1 &= ~(CHARBYTES - 1); > + align2 &= ~(CHARBYTES - 1); > + > if (n == 0) > { > s1 = (CHAR *) (buf1 + page_size); > @@ -204,6 +207,9 @@ do_test (size_t align1, size_t align2, size_t len, size_t n, int max_char, > size_t i; > CHAR *s1, *s2; > > + align1 &= ~(CHARBYTES - 1); > + align2 &= ~(CHARBYTES - 1); > + > if (n == 0) > return; Dave, Are you able to update the wiki page with your testing information? https://sourceware.org/glibc/wiki/Release/2.24 If you can't, just paste the failure lists here and the gcc/binutils/kernel version you used and I'll update it. Testing 32-bit and 64-bit information is also important to know.
From: Carlos O'Donell <carlos@redhat.com> Date: Mon, 1 Aug 2016 11:57:16 -0400 > On 07/20/2016 06:39 PM, David Miller wrote: >> I had to apply this (year old) patch to fix the wcsmbs comparison test >> case. The memory compared must be aligned suitably for the type >> being used, otherwise we get SIGBUS on platforms like sparc: >> >> diff --git a/string/test-strncmp.c b/string/test-strncmp.c >> index 8c0a331..d392248 100644 >> --- a/string/test-strncmp.c >> +++ b/string/test-strncmp.c >> @@ -156,6 +156,9 @@ do_test_limit (size_t align1, size_t align2, size_t len, size_t n, int max_char, >> size_t i, align_n; >> CHAR *s1, *s2; >> >> + align1 &= ~(CHARBYTES - 1); >> + align2 &= ~(CHARBYTES - 1); >> + >> if (n == 0) >> { >> s1 = (CHAR *) (buf1 + page_size); >> @@ -204,6 +207,9 @@ do_test (size_t align1, size_t align2, size_t len, size_t n, int max_char, >> size_t i; >> CHAR *s1, *s2; >> >> + align1 &= ~(CHARBYTES - 1); >> + align2 &= ~(CHARBYTES - 1); >> + >> if (n == 0) >> return; > > Are you able to update the wiki page with your testing information? > https://sourceware.org/glibc/wiki/Release/2.24 I can certainly do that. Would you mind if I apply the above testsuite bug fix into the tree?
diff --git a/string/test-strncmp.c b/string/test-strncmp.c index 8c0a331..d392248 100644 --- a/string/test-strncmp.c +++ b/string/test-strncmp.c @@ -156,6 +156,9 @@ do_test_limit (size_t align1, size_t align2, size_t len, size_t n, int max_char, size_t i, align_n; CHAR *s1, *s2; + align1 &= ~(CHARBYTES - 1); + align2 &= ~(CHARBYTES - 1); + if (n == 0) { s1 = (CHAR *) (buf1 + page_size); @@ -204,6 +207,9 @@ do_test (size_t align1, size_t align2, size_t len, size_t n, int max_char, size_t i; CHAR *s1, *s2; + align1 &= ~(CHARBYTES - 1); + align2 &= ~(CHARBYTES - 1); + if (n == 0) return;