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

[Peter Maydell]

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.

> For the gdbstub, we'd like to be able to invoke QEMU from GDB like:
>
> (gdb) target remote | arm-qemu-system -cpu=foo [options] /dev/null
> (gdb) load
> (gdb) ...
>
> which unfortunately bypasses the probing of the loaded ELF file (since
> it's just /dev/null) to determine whether to use BE8/BE32 mode. So,
> I added some "virtual" CPUs to set the endian type instead (arm926-be,
> cortex-a15-be for BE32/BE8 mode respectively), from the reset value
> of the SCTLR. This is kind of like having a configuration input to the
> CPU on some hardware board to select endianness, which is a completely
> legitimate thing to have, even if the implementation as-is is not really
> ideal from a software-engineering standpoint. It suffices for our current
> use-case though.

Strong 'no' for the approach of having different CPU
names, I'm afraid. What you want is to have a CPU
property which works like the hardware CPU's CFGEND
signal to set the reset value of the SCTLR.EE bit. Then
a board can use that where it would wire up CFGEND
in real hardware, and on the command line you can
have -cpu whatever,cfgend=yes (which is a bit ugly
but then it's borderline whether it makes any sense at
all for the user to be able to set the endianness on
the commandline).

(For the rest of the series: you've missed the 2.8
freeze, and I'm on holiday for most of November, so
it may be a while before I can get to it; hopefully
somebody else will step up and have a look at it.)

thanks
-- PMM