This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: [Various] libc/1161: Unable to get nscd to work on alpha
Hello,
The patch doesn't fix the problem. Now it doesn't seg.fault in
compare_and_swap, but later in prune_cache, after compare_and_swap
was called. It seems the pointers are not correct after compare_and_swap.
If I use the generic compare_and_swap function, it works more or less.
There seems to be some other problems.
Thorsten
On Wed, Jun 16, Andreas Jaeger wrote:
> >>>>> Geoff Keating writes:
>
> >> Mailing-List: contact libc-alpha-help@sourceware.cygnus.com; run by ezmlm
> >> cc: Andreas Jaeger <aj@arthur.rhein-neckar.de>,
> >> libc-alpha Mailinglist <libc-alpha@sourceware.cygnus.com>,
> >> sba@srl.caltech.edu
> >> Date: Sat, 12 Jun 1999 21:01:35 -0400
> >> From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
> >>
> >> Thorsten Kukuk <kukuk@suse.de> said:
> >> > On Sat, Jun 12, Andreas Jaeger wrote:
> >> > > Is there anything we can do to fix nscd on alpha? I fear this is a
> >> > > compiler bug:-(. Richard, can you help?
> >>
> >> > It's an older bug which I have already send twice to the egcs people
> >> > without getting an reaction.
> >> >
> >> > egcs miscompiles the following lines from nscd/cache.c:
> >> >
> >> > /* Put the new entry in the first position. */
> >> > do
> >> > newp->next = table->array[hash];
> >> > while (! compare_and_swap ((volatile long int *) &table->array[hash],
> >>
> >> Have you tried adding -fno-strict-aliases? Without it late egcs snapshots
> >> at least assume data can't be accessed through a pointer to a different
> >> type, unless it is a char pointer (this is what the standard says, and egcs
> >> follows). Bit me hard.
>
> Geoff> I notice that the ppc version of this has a bug; the assembler isn't
> Geoff> clobbering "memory". It's always necessary for compare_and_swap to
> Geoff> have a clobber of "memory" somewhere, otherwise egcs may delay a store
> Geoff> until after the compare-and-swap. I attach a patch.
>
> Geoff> The alpha version of this is different, in that it uses a "m"
> Geoff> constraint instead of taking the address like the ppc one does.
> Geoff> However, it _still_ needs a 'memory' clobber, because otherwise code
> Geoff> like:
>
> Geoff> {
> Geoff> static long lock;
> Geoff> static uint32_t lfsr;
>
> Geoff> /* Acquire a lock, spinning until we get it. */
> Geoff> while (!compare_and_swap (&lock, 0, 1)) ;
>
> Geoff> /* Change some memory location, protected by the lock. */
> Geoff> lfsr = lfsr >> 1 ^ ((lfsr & 1) ? 0x80003000 : 0);
>
> Geoff> /* Release the lock. */
> Geoff> compare_and_swap(&lock, 1, 0);
> Geoff> }
>
> Geoff> may be rescheduled by gcc so that the assignment happens before the
> Geoff> acquisition of the lock, or after the release, or even some
> Geoff> combination of the two.
>
> Geoff> Then you don't need to use -fno-strict-aliases.
>
> Does this patch look ok ? It's just for compare_and_swap, the others
> have to be fixed the same way if this is the right way to do it.
>
> Could others please check this?
>
> I'm not suggesting to add it to glibc, yet - I'd like to discuss this
> first.
>
> Andreas
>
> 1999-06-16 Andreas Jaeger <aj@arthur.rhein-neckar.de>
>
> * sysdeps/alpha/atomicity.h (compare_and_swap): Remove `volatile'
> and add `memory' clobber.
>
> --- sysdeps/alpha/atomicity.h.~1~ Fri Jan 29 17:57:43 1999
> +++ sysdeps/alpha/atomicity.h Wed Jun 16 08:31:47 1999
> @@ -77,7 +77,7 @@
> {
> long int ret;
>
> - __asm__ __volatile__ (
> + __asm__ (
> "/* Inline compare & swap */\n"
> "1:\t"
> "ldq_l %0,%4\n\t"
> @@ -94,7 +94,8 @@
> "mb\n\t"
> "/* End compare & swap */"
> : "=&r"(ret), "=m"(*p)
> - : "r"(oldval), "r"(newval), "m"(*p));
> + : "r"(oldval), "r"(newval), "m"(*p)
> + : "memory");
>
> return ret;
> }
>
> --
> Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
> for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
--
Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de
SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg
Linux is like a Vorlon. It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.