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. > 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