From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7676 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.comp.emulators.qemu Subject: Broken SuperH atomics in qemu app-level emulation Date: Sun, 17 May 2015 23:05:36 -0400 Message-ID: <20150518030536.GA14435@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1431918365 15439 80.91.229.3 (18 May 2015 03:06:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 May 2015 03:06:05 +0000 (UTC) To: musl@lists.openwall.com, qemu-devel@nongnu.org Original-X-From: musl-return-7688-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 18 05:05:59 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YuBNP-0003Zf-3k for gllmg-musl@m.gmane.org; Mon, 18 May 2015 05:05:59 +0200 Original-Received: (qmail 28166 invoked by uid 550); 18 May 2015 03:05:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28113 invoked from network); 18 May 2015 03:05:49 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7676 gmane.comp.emulators.qemu:337015 Archived-At: 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