[Top][All Lists]
[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
From: |
malc |
Subject: |
Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking |
Date: |
Sat, 20 Feb 2010 11:28:56 +0300 (MSK) |
User-agent: |
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.
>
> http://launchpadlibrarian.net/38837077/buildlog_ubuntu-lucid-armel.qemu-kvm_0.12.2-0ubuntu6_FAILEDTOBUILD.txt.gz
> [...]
> 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
> r4,r4,[r3]'
> /tmp/cc24C9yx.s:6599: Error: selected processor does not support `swp
> r6,r6,[r3]'
> make[2]: *** [exec.o] Error 1
> make[1]: *** [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?
Yes.
>
> 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
> list?
For instance this:
http://sources.redhat.com/ml/libc-alpha/2005-06/msg00112.html
The builtins are too coarse grained and will do more stuff than strictly
necessary.
--
mailto:address@hidden
Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking, Paul Brook, 2010/02/27