[ltt-dev] [PATCH 07/11] add uatomic_gcc.h, use it for default definitions

[Mathieu Desnoyers]

* Paolo Bonzini (pbonzini at redhat.com) wrote:
> On 02/14/2010 03:45 PM, Mathieu Desnoyers wrote:
>>> >  - if cmpxchg is present, use it to implement xchg and add_return;
>>
>> Not sure I understand this comment, and not sure it matches the patch.
>> x86 has xchg() which is faster than a cmpxchg-based fallback, and you
>> seem to leave the code as-is. Can you elaborate ?
>
> Each per-architecture file can provide its own xchg and add_return which  
> are then used instead of the defaults.  For example, x86 uses entirely  
> custom code, and PPC uses its own implementation of xchg (since it is  
> also much faster than cmpxchg on ll/sc machines).

OK. Please update the changelog comment with the information above.

>
> Basically, in this case uatomic_gcc.h is using the approach of  
> uatomic_arch_sparc64.h.
>
>>> >  - if it is not present, implement all three using __sync_* builtins
>>
>> Starting from which gcc versions does these __sync_* builtins work ?
>> (question applies for the builtin memory barrier too).
>
> The builtins appeared in 4.2, but they were backported to 4.1 by some  
> vendors.
>
> Note that on SPARC64 and S390 they were already needed to build the  
> library because the tests used them.urcu-bp-static.h.  However the  
> clients of liburcu did not need the compiler to have __sync builtins.

For __builtin_trap() I suspect. This could be changed if needed.

>
> After this patch, a new compiler is necessary on S390 and PPC to use the  
> following files:
>
> urcu-bp-static.h:#include <urcu/uatomic_arch.h>
> urcu-defer-static.h:#include <urcu/uatomic_arch.h>
> urcu-pointer-static.h:#include <urcu/uatomic_arch.h>
> urcu-pointer.h:#include <urcu/uatomic_arch.h>
> urcu-qsbr-static.h:#include <urcu/uatomic_arch.h>
> urcu-static.h:#include <urcu/uatomic_arch.h>
>
> I'll test a patch to remove the inclusion from urcu-pointer.h since it  
> seems unnecessary to me.

How do you plan to let people publish and dereference RCU data then ?

>
> After this, a client that is interested in using an older GCC can thus  
> use _LGPL_SOURCE if it finds a compiler that is not new enough.  I can  
> also make this automatic if you prefer.

Hrm, that's a problem. We cannot just say "hey, update the test systems
you are working with to newer compilers" to people who often only borrow
these systems and have to deal with the very often deprecated toolchains
available. This is the case for a 64-core POWER5+ we are doing testing
on: we're stuck with an old gcc.

Paul, what's the oldest gcc versions you think would be sane to support ?

Thanks,

Mathieu

>
> Paolo
>

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68