Re: [Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub support.

[Julian Brown]

On Thu, 3 Nov 2016 22:23:09 +0000
Peter Maydell <address@hidden> wrote:

> On 3 November 2016 at 17:30, Julian Brown <address@hidden>
> 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