I'm using r223407. Switching to a clean built on r223853, it still gives
me:
ldr x8, [x21,#8]
stp x21, x8, [x19]
dmb ishst
ldr x8, [x19,#8]
str x19, [x8]
str x19, [x21,#8]
Thanks,
Chengyu
> On Dec 9, 2014, at 6:32 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
>
> On 9 December 2014 at 15:14, Chengyu Song <csong84 at gatech.edu>
wrote:
>> Errr. my fault. I patched the rcu_assign_pointer ... Let me try again.
>
> It's looking closer now, but I still can't trigger the bug I'm
afraid.
> Even disabling the load/store optimiser and fiddling with CPUs (to try
> different schedulers) just gives me what I'd expect:
>
> ldr x8, [x21, #8]
> str x21, [x19]
> str x8, [x19, #8]
> dmb ishst
> ldr x8, [x19, #8]
> str x19, [x8]
>
> I'm not aware of any big changes in this area recently. You don't
have
> any local LLVM patches or anything that could be causing the problem?
> What revision of trunk did you get it to fail on? I could try checking
> that one out.
>
> Cheers.
>
> Tim.
On 9 December 2014 at 16:01, Chengyu Song <csong84 at gatech.edu> wrote:> I'm using r223407.Just trying out this build now. Hopefully I'll be able to see the error too there.> Switching to a clean built on r223853, it still gives me: > > ldr x8, [x21,#8] > stp x21, x8, [x19] > dmb ishst > ldr x8, [x19,#8] > str x19, [x8] > str x19, [x21,#8]Isn't that correct though? The problematic "str" has been folded into the "stp" instruction, so "x19 + 8" is written before it gets read. Cheers. Tim.
>> Switching to a clean built on r223853, it still gives me: >> >> ldr x8, [x21,#8] >> stp x21, x8, [x19] >> dmb ishst >> ldr x8, [x19,#8] >> str x19, [x8] >> str x19, [x21,#8] > > Isn't that correct though? The problematic "str" has been folded into > the "stp" instruction, so "x19 + 8" is written before it gets read.Indeed. I didn't pay too much attention to the str -> stp change. Unfortunately, the trunk build crashes when compiling the kernel. Hope it will be fixed tomorrow, else I need to find a revision that gives me this fix. Thank you so much! Chengyu