From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2RWp-0007KN-3B for qemu-devel@nongnu.org; Thu, 03 Nov 2016 19:34:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2RWk-0005VY-6f for qemu-devel@nongnu.org; Thu, 03 Nov 2016 19:34:39 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:57961) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c2RWk-0005VH-0O for qemu-devel@nongnu.org; Thu, 03 Nov 2016 19:34:34 -0400 Date: Thu, 3 Nov 2016 23:34:19 +0000 From: Julian Brown Message-ID: <20161103233419.26f4b7c7@squid.athome> In-Reply-To: References: <1478194258-75276-1-git-send-email-julian@codesourcery.com> <1478194258-75276-2-git-send-email-julian@codesourcery.com> 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: Peter Maydell Cc: QEMU Developers On Thu, 3 Nov 2016 22:23:09 +0000 Peter Maydell wrote: > On 3 November 2016 at 17:30, Julian Brown > wrote: > > This patch improves support for semihosting and debugging with the > > in-built gdbstub for ARM system-mode emulation in big-endian mode > > (either BE8 or BE32), after the fairly recent changes to allow a > > single QEMU binary to deal with each of LE, BE8 and BE32 modes in > > one. It's only currently good for little-endian host systems. The > > relevant use case is using QEMU as a "bare metal" instruction-set > > simulator, e.g. for toolchain testing. > > > > For semihosting, the softmmu-semi.h file is overridden with an > > ARM-specific version that knows about byte-swapping target memory > > into host order -- including that which has been byte-swapped at > > load time for BE32 mode. > > Something here seems really weird. I would expect gdb > to be able to cope with the target CPU's endianness > settings. After all there is real world code which > starts off in one endianness, temporarily swaps to > the other and then switches back again, and gdb needs > to be able to step through it without issues. So having > code in the gdbstub interface that looks at arm_bswap_needed() > seems rather odd and in the wrong place. What the guest > CPU happens to be doing at any particular point shouldn't > affect the way we talk to gdb. I think the way it works is, if you invoke GDB with something like, $ arm-eabi-gdb big-endian-binary.elf then the remote protocol will talk in big-endian format (memory read/write packets, register read/write packets, etc.) for that session. I'm not sure if it'll transparently switch to little-endian remote protocol format if the target does a SETEND instruction, or whatever. I'd guess not. 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. 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. Thanks, Julian