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:av1...@comtv.ru