From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2bgl-0004VM-Ng for qemu-devel@nongnu.org; Fri, 04 Nov 2016 06:25:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2bgi-00028f-Fh for qemu-devel@nongnu.org; Fri, 04 Nov 2016 06:25:35 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:47928) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c2bgi-00027K-9r for qemu-devel@nongnu.org; Fri, 04 Nov 2016 06:25:32 -0400 Date: Fri, 4 Nov 2016 10:25:16 +0000 From: Julian Brown Message-ID: <20161104102516.301c8bbe@squid.athome> In-Reply-To: References: <1478194258-75276-1-git-send-email-julian@codesourcery.com> <1478194258-75276-2-git-send-email-julian@codesourcery.com> <20161103233419.26f4b7c7@squid.athome> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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: Paolo Bonzini Cc: Peter Maydell , QEMU Developers On Fri, 4 Nov 2016 09:48:06 +0100 Paolo Bonzini wrote: > 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? Yes, exactly. I think we more-or-less just added a armeb-softmmu.mak and things worked -- at least as far as BE32 mode, and bearing in mind that we were only interested in instruction-set simulation. BE8 mode is (ahem) a different matter, i.e. we (as in Mentor) might just have been getting that wrong. Oops! > 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. OK, that makes sense, thanks. > 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. The splitting-into-bytes is just an implementation convenience -- the simplest way I could see of handling the low-order address bit reversal without breaking abstractions more or shuffling lots of code around. I'm not sure if GDB was actually requesting sub-word access sizes. Thanks, Julian