Broken SuperH atomics in qemu app-level emulation

[Rich Felker <dalias@libc.org>]

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