From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56782) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7hov-0005eT-Ds for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:22:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7hor-0001O4-Ej for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:22:17 -0400 Received: from mail-vn0-f44.google.com ([209.85.216.44]:41906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7hor-0001Ny-8y for qemu-devel@nongnu.org; Wed, 24 Jun 2015 06:22:13 -0400 Received: by vnav203 with SMTP id v203so5601160vna.8 for ; Wed, 24 Jun 2015 03:22:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <558A81DC.5090402@redhat.com> References: <1403355502-12288-1-git-send-email-pbonzini@redhat.com> <1403355502-12288-5-git-send-email-pbonzini@redhat.com> <53AC2B9B.40801@redhat.com> <558A81DC.5090402@redhat.com> From: Peter Maydell Date: Wed, 24 Jun 2015 11:21:53 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v3 04/11] linux-user: arm: set CPSR.E correctly for BE8 mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Crosthwaite , QEMU Developers On 24 June 2015 at 11:09, Paolo Bonzini wrote: > > > On 23/06/2015 22:30, Peter Crosthwaite wrote: >> > I'm confused. arm_cpu_is_big_endian() tells you whether the CPU >> > is *currently* big-endian or not. That doesn't help you with >> > answering the question "I'm about to run a signal handler; what >> > should I set the CPSR.E bit to?" in linux-user mode. That's >> > what signal_cpsr_e does. >> >> arm_cpu_is_bigendian is the consumer of this information. We still >> need some state for signal_cpsr_e, just the question is what state >> does that set. If we reuse arm_cpu_is_big_endian, then signal_cpsr_e >> (or its rename) needs to drive CPSR.E as well as SCTLR.E0E. > > I think signal_cpsr_e is exactly what you want for AArch32. It sets > CPSR.E in main and setup_return for AArch32. > > For AArch64 you don't need anything because, even though the kernel does > trap setend and tweak SCTLR.E0E in response to it, setup_return doesn't > try to restore the native endianness. I didn't think SETEND existed at all in AArch64? It's a 32-bit only instruction. So the AArch64 setup is anyway much simpler because you don't have to worry about the userspace code being a different endianness to what you want to run the signal handler as. -- PMM