[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for lock
Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking
Sat, 20 Feb 2010 11:28:56 +0300 (MSK)
Alpine 2.00 (LNX 1167 2008-08-23)
On Sat, 20 Feb 2010, Lo?c Minier wrote:
> NB: Addition of these builtins was prompted by qemu failing to build on
> armel in Ubuntu; this is because we default to Thumb 2 mode which
> doesn't have the assembly instructions in question.
> CC arm-softmmu/syborg_virtio.o
> CC arm-softmmu/exec.o
> /tmp/cc24C9yx.s: Assembler messages:
> /tmp/cc24C9yx.s:5392: Error: selected processor does not support `swp
> /tmp/cc24C9yx.s:6599: Error: selected processor does not support `swp
> make: *** [exec.o] Error 1
> make: *** [subdir-arm-softmmu] Error 2
> On Sat, Feb 20, 2010, malc wrote:
> > Please look up "gcc 4.1 implements compiler builtins for atomic ops"
> > thread for reasons why this might not be the best idea.
> I found a very old thred (2005) on libc-alpha with this subject; is
> this the one you mean?
> People participating in the libc-alpha were not really constructive and
> were presenting some bogus arguments; let me try to go over the various
> arguments (long):
> - some people wanted atomic builtins to be inline for performance and
> others wanted them to be library calls to allow changing their
> behavior later (e.g. to support a new CPU); the implementation
> actually uses both: inline assembly when supported on the
> architecture, or calls into libgcc which will call into the kernel
> otherwise (or direct calls into the kernel when building statically
> obviously), such as when the ISA doesn't offer sufficient primitives.
> Because *any* instruction might be gotten wrong in hardware, I don't
> see a need to special case locking inline assembly.
> - userspace apps abusing atomic builtins for locking; this is actually
> the case of qemu, but I think using gcc primitives will actually make
> it easier to get it right and will allow coverage of more
> architectures; in my opinion, there's no need to maintain
> hand-written assembly for locks in 2010.
> - someone claimed that modern architectures can do these operations in
> assembly without calling into a library; that's what the atomic
> builtins do, and actually some modern architectures can't do all
> operations in assembly.
> - there were arguments over where such functions belong and the
> semantics of each call; these are in my eyes purely political and
> don't relate to qemu.
> Which are your concerns with atomic builtins and are these in the above
For instance this:
The builtins are too coarse grained and will do more stuff than strictly
Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking, Paul Brook, 2010/02/27