[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150518030536.GA14435@brightrain.aerifal.cx>
Date: Sun, 17 May 2015 23:05:36 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com, qemu-devel@...gnu.org
Subject: Broken SuperH atomics in qemu app-level emulation
While testing the inline sh4a atomics patch for musl (see
http://www.openwall.com/lists/musl/2015/05/17/22) I noticed that
qemu-sh4 crashed on the instructions used for atomics, which are only
available in sh4a. Adding -cpu SH7785 made it work, but that got me
wondering what's happening when we don't build musl with -m4a
(resulting in the new inline atomics) but instead use a more baseline
target like -m4 where the type of atomics to use has to be detected at
runtime.
musl's runtime atomic detection for SuperH is based on the
CPU_HAS_LLSC bit of AT_HWCAP. Under qemu app-level emulation, the
value for AT_HWCAP is always 0, even with -cpu SH7785. This causes
musl to choose the GUSA atomics, rather than the actual atomic
instructions. That's a big problem, because there's no way GUSA can
work with app-level emulation; the whole concept of GUSA relies on the
kernel detecting that it preempted a GUSA atomic sequence and
resetting the program counter the next time the task is scheduled, but
app-level emulation has no kernel and no control over scheduling, and
thus no way to make GUSA work.
At the very least qemu-sh4 should provide a correct value of AT_HWCAP
so we get working atomics with -cpu SH7785. And since the GUSA atomic
model can't work with app-level emulation, I really think qemu-sh4
should either default to -cpu SH7785 or always expose the
synco/mov.li/mov.co opcodes (and hwcap) regardless of the -cpu
setting.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
