linux-mips
[Top] [All Lists]

Re: locking problems with mips atomicity ?

To: Harm Verhagen <hverhagen@dse.nl>
Subject: Re: locking problems with mips atomicity ?
From: Daniel Jacobowitz <dan@debian.org>
Date: Tue, 20 Apr 2004 18:56:26 -0400
Cc: linux-mips@linux-mips.org
In-reply-to: <1082501636.13783.69.camel@node-d-8d2e.a2000.nl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1082501074.13783.54.camel@node-d-8d2e.a2000.nl> <20040420224904.GA21924@nevyn.them.org> <1082501636.13783.69.camel@node-d-8d2e.a2000.nl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.5.1+cvs20040105i
On Wed, Apr 21, 2004 at 12:53:56AM +0200, Harm Verhagen wrote:
> On Wed, 2004-04-21 at 00:49, Daniel Jacobowitz wrote:
> > On Wed, Apr 21, 2004 at 12:44:34AM +0200, Harm Verhagen wrote:
> > > The code from linux 2.4.26 arch-mips/atomic.h looks _very_ similar to
> > > the code described in the thread that has a BUG.
> > > 
> > > 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.
> Sorry for not understanding completely. What makes the gcc code PIC
> then? The code looks similar, an inline function with inline assembly.
> Could you elaborate ?

You may want to look for documentation describing the MIPS PIC
conventions.  Good luck; they're bizarre.

The problem is that in userspace "ll $2, symbol_name" may expand to a
load of the address of symbol_name from the GOT (global offset table).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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