[ltt-dev] [PATCH 07/11] add uatomic_gcc.h, use it for default definitions
Paolo Bonzini
pbonzini at redhat.com
Mon Feb 15 03:06:32 EST 2010
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).
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.
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.
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. It's
not really good to make this automatic because if someone for example
cares about x86 only, they are fine using _LGPL_SOURCE with any compiler
version.
Paolo
More information about the lttng-dev
mailing list