From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0B4M-0008QS-CB for qemu-devel@nongnu.org; Thu, 26 Jun 2014 10:54:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0B46-00030P-Mo for qemu-devel@nongnu.org; Thu, 26 Jun 2014 10:54:34 -0400 Received: from mail-lb0-f169.google.com ([209.85.217.169]:33237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0B46-00030F-FZ for qemu-devel@nongnu.org; Thu, 26 Jun 2014 10:54:18 -0400 Received: by mail-lb0-f169.google.com with SMTP id l4so3063031lbv.0 for ; Thu, 26 Jun 2014 07:54:17 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <53AC2B08.8030404@redhat.com> References: <1403355502-12288-1-git-send-email-pbonzini@redhat.com> <1403355502-12288-4-git-send-email-pbonzini@redhat.com> <53AC2B08.8030404@redhat.com> From: Peter Maydell Date: Thu, 26 Jun 2014 15:53:57 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v3 03/11] target-arm: implement SCTLR.B, drop bswap_code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: QEMU Developers On 26 June 2014 15:15, Paolo Bonzini wrote: > Il 26/06/2014 16:01, Peter Maydell ha scritto: >> On 21 June 2014 13:58, Paolo Bonzini wrote: >>> bswap_code is a CPU property of sorts ("is the iside endianness the >>> opposite way round to TARGET_WORDS_BIGENDIAN?") but it is not the >>> actual CPU state involved here which is SCTLR.B (set for BE32 >>> binaries, clear for BE8). >>> >>> Replace bswap_code with SCTLR.B, and pass that to arm_ld*_code. >>> The next patches will make data fetches honor both SCTLR.B and >>> CPSR.E appropriately. >>> >>> Signed-off-by: Paolo Bonzini >> >>> @@ -4191,11 +4191,19 @@ int main(int argc, char **argv, char **envp) >>> for(i = 0; i < 16; i++) { >>> env->regs[i] = regs->uregs[i]; >>> } >>> +#ifdef TARGET_WORDS_BIGENDIAN >>> /* Enable BE8. */ >>> if (EF_ARM_EABI_VERSION(info->elf_flags) >= EF_ARM_EABI_VER4 >>> && (info->elf_flags & EF_ARM_BE8)) { >>> - env->bswap_code = 1; >>> + /* nothing for now, CPSR.E not emulated yet */ >>> + } else { >>> + if (arm_feature(env, ARM_FEATURE_V7)) { >>> + fprintf(stderr, "BE32 binaries only supported until ARMv6\n"); >>> + exit(1); >>> + } >>> + env->cp15.c1_sys |= SCTLR_B; >> >> This will break running BE32 binaries with "-cpu any" >> (which sets all the features we know about, including >> ARM_FEATURE_V7). > > Yes, this was on purpose. I would expect that anybody running BE32 binaries is probably running them with -cpu any, since it's the default. So breaking them is a bit harsh... >>> +static inline bool bswap_code(bool sctlr_b) >>> +{ >>> +#ifdef CONFIG_USER_ONLY >>> + /* Mixed-endian modes are BE8 (SCTLR.B = 0, TARGET_WORDS_BIGENDIAN = 1) >>> + * and "LE8" (SCTLR.B = 1, TARGET_WORDS_BIGENDIAN = 0). >> >> Huh? LE8 is SCTLR.B == 0... > > I think LE8 is an R core with SCTLR.IE=1 SCTLR.EE=1 but CPSR.E=0, i.e. > little endian data and big-endian code. I put it in quotes because I > get this with SCTLR.B=1 CPSR.E=1. The difference is user visible due > to CPSR.E. That's not what I would interpret "LE8" to mean... (I don't actually think we define that term at all, but I would have taken it to mean 'a BE8-capable system in little-endian mode', ie CPSR.E==0 SCTLR.B==0). SCTLR.B==1 CPSR.E==1 is UNPREDICTABLE and so we need not care at all what it does. If you want you can add a remark about our not supporting SCTLR.IE since we don't support any ARMv6/ARMv7 R-class cores, but I don't think that's really necessary. > I can modify the comment to: > > /* BE8 (SCTLR.B = 0, TARGET_WORDS_BIGENDIAN = 1) is mixed endian. > * The invalid combination SCTLR.B=1/CPSR.E=1/TARGET_WORDS_BIGENDIAN=0 > * would also end up as a mixed-endian mode with BE code, LE data. > */ Yeah, that's fine. thanks -- PMM