From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NikiM-0000YK-4P for qemu-devel@nongnu.org; Sat, 20 Feb 2010 03:29:26 -0500 Received: from [199.232.76.173] (port=39526 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NikiH-0000Xe-RF for qemu-devel@nongnu.org; Sat, 20 Feb 2010 03:29:22 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NikiF-0000F4-IZ for qemu-devel@nongnu.org; Sat, 20 Feb 2010 03:29:21 -0500 Received: from fe02x03-cgp.akado.ru ([77.232.31.165]:59020 helo=akado.ru) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NikiF-0000Ev-6R for qemu-devel@nongnu.org; Sat, 20 Feb 2010 03:29:19 -0500 Date: Sat, 20 Feb 2010 11:28:56 +0300 (MSK) From: malc Subject: Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking In-Reply-To: <20100220081625.GA9788@bee.dooz.org> Message-ID: References: <1266613360-23069-1-git-send-email-lool@dooz.org> <20100220081625.GA9788@bee.dooz.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Lo=EFc_Minier?= Cc: qemu-devel@nongnu.org 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:av1474@comtv.ru