Re: Errata 67/77 / walnut bugs (was: Re: Erratum 51 bugfix?)

[dank@kegel.com]

Mark Hatle wrote:
> The atonicity patches had not been submitted back to glibc due to there being
> now way for me to show it was needed

That *is* a problem, isn't it?  We have a test case, but not one we
can distribute.  I'm trying to create a clean one that can be distributed,
but this bug is hard to trigger.

> and also that it ONLY affects the 405 CPU,
> which isn't the main target of glibc.
>
> We are currently working on revising our glibc patches to the current CVS
> version, and if a new patch is required I'll make sure it gets posted here.  I
> really don't know the best way to handle this in a community glibc/gcc realm.
> I'd almost like to wait and see what the GCC maintainers response is.
> Specifically how they are going to accept the patch.  Then we propose a similar
> thing to the glibc folks, explain the problem and hope they accept the patch as
> well.  The biggest problem of course is that if we enable this for all PPCs
> we're going to take a performance penalty for CPUs that don't have the problem.

The patch can be made conditional, so that by default it affects nothing.
The libstdc++ mailing list has already blessed the part of the change
that affects them.

Here's how to do it:

1. Arrange for gcc to define __PPC405__ when appopriate by changing
gcc/config/rs6000/rs6000.h:

-%{mcpu=405: -D_ARCH_PPC} \
+%{mcpu=405: -D_ARCH_PPC -D__PPC405__} \

2. Surround the workaround with #ifdef __PPC405__.  For instance,
in gcc-3.0.2/libstdc++-v3/config/cpu/powerpc/bits/atomicity.h:

+#ifdef __PPC405__
+#define        __LIBSTDCPP_PPC405_ERR77_SYNC   "sync \n\t"
+#else
+#define __LIBSTDCPP_PPC405_ERR77_SYNC
+#endif
+
 static inline _Atomic_word
 __attribute__ ((__unused__))
 __exchange_and_add (volatile _Atomic_word* __mem, int __val)
@@ -42,6 +54,7 @@
        "0:\t"
        "lwarx    %0,0,%2 \n\t"
        "add%I3   %1,%0,%3 \n\t"
+       __LIBSTDCPP_PPC405_ERR77_SYNC

3. Arrange for ppc405-specific libraries to be generated.  I'm
still working on this, but it's something like

--- gcc/config/rs6000/t-ppcos.orig
+++ gcc/config/rs6000/t-ppcos
@@ -1,7 +1,7 @@
 # Multilibs for a powerpc hosted ELF target (linux, SVR4, solaris)

-MULTILIB_OPTIONS       = msoft-float
-MULTILIB_DIRNAMES      = nof
+MULTILIB_OPTIONS       = msoft-float/mcpu=405
+MULTILIB_DIRNAMES      = nof ppc405

4. Arrange to suppress generation of ppc405-specific libraries by default.
I have yet to do this, but it's probably a change to gcc/config-ml.in
to add an --enable-ppc405 option.

I could use help in two areas:
figuring out how to generate many interrupts on the ppc405 to make
a regression test more likely to run into the problem (see my previous
post to linuxppc-embedded), and
figuring out how gcc's MULTILIB_EXCEPTIONS parameter (I'll be posting
to the gcc list about that, so hopefully some expert there will
give me a clue).

Oh, and it'd be nice to hear what you think of my patch to gcc3, too.

It'd be nice to get ppc405 support in the gcc/glibc mainline, glad to hear
you're working on it too!
- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/