[cacao] RFC: CACAO PR157 ARM memory barrier patch

[Robert Lougher]

On 11 March 2011 16:31, Andrew Haley <aph at redhat.com> wrote:
> On 03/11/2011 04:27 PM, Robert Lougher wrote:
>> On 11 March 2011 15:55, Andrew Haley <aph at redhat.com> wrote:
>>> On 03/11/2011 03:48 PM, Robert Lougher wrote:
>>>>
>>>> This is how I define MBARRIER for ARM in JamVM:
>>>>
>>>> #ifdef __ARM_ARCH_7A__
>>>> #define MBARRIER() __asm__ __volatile__ ("dmb" ::: "memory")
>>>> #else
>>>> #define MBARRIER() __asm__ __volatile__ ("" ::: "memory")
>>>> #endif
>>>
>>> But that's wrong for GNU/Linux binaries, surely.
>>
>> Ubuntu defaults to ARMv7 and Thumb2, so this is OK for Ubuntu.  But
>> yes, I believe Debian builds binaries for ARMv4t.  I can understand
>> this in the past, as older binaries would run with no problem on later
>> chips.  But ARMv7 needs proper memory barriers, so I don't think the
>> Debian policy makes any sense here.  Using the kernel helper like this
>> just seems nasty to me (defining a function pointer via __kernel_dmb
>> (*(__kernel_dmb_t *) 0xffff0fa0)).
>
> In what way is it nasty?  You get the correct behaviour with very little
> overhead.
>

These barriers are used in the thin-locking code.  The fast path in
the lock should only be a few instructions.  This will add significant
overhead.

Rob.

>> My opinion is that if you build for ARMv4t, don't expect it to run on ARMv7.
>
> I don't get it.  Why not just do it right for all cases?
>
> Andrew.
>