Hi Ali,
I agree that this seems not to be an M5 problem. I am rebuilding the
crosscompiler now and I don't have the trace at this time. But as far as I
remember, the inlined assembly in __spin_unlock
__asm__ __volatile__ ("mb; stq $31, %0; mb"
: "=m" (__lock));
stores zero into __lock's address. But what the program meant is to store zero
to __lock. So I just changed it to (*__lock).
Actually, it's easier to guess that a "*" is missed in __spin_unlock's inline
assembly if we compare __spin_unlock to __spin_try_lock, which looks like this:
============================
/* Try to lock LOCK; return nonzero if we locked it, zero if another has. */
int
__spin_try_lock (register __spin_lock_t *__lock)
{
register long int __rtn, __tmp;
do
{
__asm__ __volatile__ ("mb; ldq_l %0,%1" /* Load lock value into TMP. */
: "=r" (__tmp) : "m" (*__lock));
__rtn = 2; /* Load locked value into RTN. */
if (__tmp)
/* The lock is already taken. */
return 0;
/* The lock is not taken; try to get it now. */
__asm__ __volatile__ ("stq_c %0,%1"
: "=r" (__rtn), "=m" (*__lock)
: "0" (__rtn), "1" (*__lock));
/* RTN is clear if stq_c was interrupted; loop to try the lock again. */
} while (! __rtn);
/* RTN is now nonzero; we have the lock. */
return __rtn;
}
============================
FYI.
----- Original Message -----
From: "Ali Saidi" <[EMAIL PROTECTED]>
To: "M5 users mailing list" <m5-users@m5sim.org>
Sent: 2007年6月21日 9:11 AM
Subject: Re: [m5-users] synchronization primitives in SE mode
> I
> On Jun 20, 2007, at 7:52 PM, Jiayuan Meng wrote:
>
>> Hi Steve,
>>
>>>
>>> Also, what happens if you run with AtomicSimpleCPU, and with or
>>> without
>>> a single level of caches?
>> I manually used the mutex_lock in glibc's sysdeps/mach/alpha/
>> machine-lock.h, the LL/SC worked fine with both configurations.
>> (L1 & L2 / L1 only)
>>
>> I am still trying to figure out how to configure the right build
>> environment. I tried crosstool gcc-4.1.1-glibc-2.3.5-nptl.dat and
>> gcc-3.4.5-glibc-2.3.5-tls.dat, but malloc just simply craches. I'm
>> diving into crosstool now. Maybe there are some configurations I
>> need to tune to rebuild glibc and make malloc include the right
>> header. I'm not sure whether crosstool really support nptl (at
>> lease on their website, version 0.42 doesn't).
>
> I've never tried to compile an nptl version so I can't be any help.
>
>>
>> FYI, I think there is a bug in glibc-2.3.5 sysdeps/mach/alpha/
>> machine-lock.h
>> 1: void
>> 2: __spin_unlock (__spin_lock_t *__lock)
>> 3: {
>> 4: __asm__ __volatile__ ("mb; stq $31, %0; mb"
>> 5: : "=m" (__lock));
>> 6: }
>>
>> according to the M5 trace, the lock isn't freed unless line 5 is
>> changed to:
>> : "=m" (*__lock));
> Do you happen to have a trace of the m5 traces that fail and don't?
> Maybe the disassembled function from the binary that fails and the
> one that doesn't? It might be a compiler/assembler problem, but it
> might also be that we are handling the mb incorrectly. Did this
> happen on a simple-cpu (if so it's definitely the compiler/assembler).
>
> Ali
> _______________________________________________
> m5-users mailing list
> m5-users@m5sim.org
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
