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.