From: "Loïc Minier" <lool@dooz.org>
To: malc <av1474@comtv.ru>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking
Date: Sat, 20 Feb 2010 09:16:25 +0100 [thread overview]
Message-ID: <20100220081625.GA9788@bee.dooz.org> (raw)
In-Reply-To: <alpine.LNX.2.00.1002200036500.7525@linmac>
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?
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?
--
Loïc Minier
next prev parent reply other threads:[~2010-02-20 8:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-19 21:02 [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking Loïc Minier
2010-02-19 21:02 ` [Qemu-devel] [PATCH 2/2] Make spinlock_t types volatile Loïc Minier
2010-02-19 21:42 ` [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking malc
2010-02-20 8:16 ` Loïc Minier [this message]
2010-02-20 8:28 ` malc
2010-02-20 9:10 ` Loïc Minier
2010-02-20 17:57 ` malc
2010-02-22 10:25 ` Loïc Minier
2010-02-22 10:47 ` malc
2010-02-28 0:26 ` Paul Brook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100220081625.GA9788@bee.dooz.org \
--to=lool@dooz.org \
--cc=av1474@comtv.ru \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).