On Thu, 3 Nov 2016 22:23:09 +0000 Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 3 November 2016 at 17:30, Julian Brown <jul...@codesourcery.com> > 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
