Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking

[malc]

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