From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2aAY-0003pZ-E9 for qemu-devel@nongnu.org; Fri, 04 Nov 2016 04:48:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2aAV-0008Rc-Bb for qemu-devel@nongnu.org; Fri, 04 Nov 2016 04:48:14 -0400 Received: from mail-wm0-x244.google.com ([2a00:1450:400c:c09::244]:35255) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c2aAV-0008PG-4c for qemu-devel@nongnu.org; Fri, 04 Nov 2016 04:48:11 -0400 Received: by mail-wm0-x244.google.com with SMTP id 68so2785395wmz.2 for ; Fri, 04 Nov 2016 01:48:10 -0700 (PDT) Sender: Paolo Bonzini References: <1478194258-75276-1-git-send-email-julian@codesourcery.com> <1478194258-75276-2-git-send-email-julian@codesourcery.com> <20161103233419.26f4b7c7@squid.athome> From: Paolo Bonzini Message-ID: Date: Fri, 4 Nov 2016 09:48:06 +0100 MIME-Version: 1.0 In-Reply-To: <20161103233419.26f4b7c7@squid.athome> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub support. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Julian Brown , Peter Maydell Cc: QEMU Developers On 04/11/2016 00:34, Julian Brown wrote: > > So (IIRC!) the gdbstub needs to interpret some of these read/write > values on the host, i.e. in host byte ordering. "Traditionally", the > ldl_p and stl_p (etc.) macros would byteswap depending on the > TARGET_WORDS_BIGENDIAN setting -- that's how come our internal testing > using QEMU worked at all in the past. But that's changed with the > single-binary-for-all-endiannesses patches. I'm not sure what you mean here... BE8 wasn't supported at all in system emulation mode before those patches, and there are still two binaries for user-mode little-endian on one side and BE8/BE32 on the other. The details of how QEMU distinguished BE8 from BE32 changed (from bswap_code to SCTLR.B and CPSR.E) but TARGET_WORDS_BIGENDIAN remained set for qemu-armeb. The difference for user-mode in fact was very small; for system mode emulation it was larger because QEMU grew support for all three of CPSR.E, SCTLR.B and SCTLR.EE. But then again there was no qemu-system-armeb before, maybe it was something you had in your internal QEMU? That said, if indeed gdb expects wire endianness to match ELF endianness, you have to do something about it indeed in the gdbstub. But it seems weird to look at CPSR.E, as that would flip values across SETEND. SCTLR.B|SCTLR.EE seems more plausible. The addition of a CPU property for reset, as suggested by Peter, would then make a lot of sense. Each CPU initfn would then look at that property and use it to initialize (depending on the model) either SCTLR.B or SCTLR.EE. The change to arm_cpu_memory_rw_debug for BE32 is also interesting. gdb documentation says The stub need not use any particular size or alignment when gathering data from memory for the response; even if ADDR is word-aligned and LENGTH is a multiple of the word size, the stub is free to use byte accesses, or not. while your change means that gdb actually wants you to do byte accesses. Paolo > So -- all uses of ld*_p and st*_p, and the TARGET_WORDS_BIGENDIAN > macro, are now suspect in ARM system-emulation mode. The gdbstub.c > changes appear to fix some of those, but... yeah, there may be > subtleties remaining, like run-time endian switching by the target. > Generally it's not ideal, but I'm not sure how to do better.