linux-mips
[Top] [All Lists]

Re: locking problems with mips atomicity ?

To: Daniel Jacobowitz <dan@debian.org>
Subject: Re: locking problems with mips atomicity ?
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Wed, 21 Apr 2004 14:43:10 +0200 (CEST)
Cc: Harm Verhagen <hverhagen@dse.nl>, linux-mips@linux-mips.org
In-reply-to: <20040420224904.GA21924@nevyn.them.org>
Organization: Technical University of Gdansk
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1082501074.13783.54.camel@node-d-8d2e.a2000.nl> <20040420224904.GA21924@nevyn.them.org>
Sender: linux-mips-bounce@linux-mips.org
On Tue, 20 Apr 2004, Daniel Jacobowitz wrote:

> > static __inline__ void atomic_add(int i, atomic_t * v)
> > {
> >     unsigned long temp;
> > 
> >     __asm__ __volatile__(
> >             "1:   ll      %0, %1      # atomic_add\n"
> >             "     addu    %0, %2                  \n"
> >             "     sc      %0, %1                  \n"
> >             "     beqz    %0, 1b                  \n"
> >             : "=&r" (temp), "=m" (v->counter)
> >             : "Ir" (i), "m" (v->counter));
> > }
> > 
> > So I wonder if there is a bug here. 
> > Can some MIPS guru check ? :)
> 
> It won't be a problem in the kernel.  The problem only happens when the
> assembler expands a macro to multiple instructions including a load,
> and that only happens for position-independent code; the kernel is not
> PIC.

 And if using a function like the above is to be PIC, the solution is to
use the "R" constraint for the ll/sc memory operand to assure it's passed
to gas as a machine-expressible address, although I'm not sure if that's
currently handled by gcc correctly (2.95.x definitely has problems with
it; I'm going to look into it for 3.5.0 soon).

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>