On 04/11/2016 00:34, Julian Brown wrote:
>
> 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.
I'm not sure what you mean here... BE8 wasn't supported at all in
system emulation mode before those patches, and there are still two
binaries for user-mode little-endian on one side and BE8/BE32 on the
other. The details of how QEMU distinguished BE8 from BE32 changed
(from bswap_code to SCTLR.B and CPSR.E) but TARGET_WORDS_BIGENDIAN
remained set for qemu-armeb.
The difference for user-mode in fact was very small; for system mode
emulation it was larger because QEMU grew support for all three of
CPSR.E, SCTLR.B and SCTLR.EE. But then again there was no
qemu-system-armeb before, maybe it was something you had in your
internal QEMU?
That said, if indeed gdb expects wire endianness to match ELF
endianness, you have to do something about it indeed in the gdbstub.
But it seems weird to look at CPSR.E, as that would flip values across
SETEND. SCTLR.B|SCTLR.EE seems more plausible. The addition of a CPU
property for reset, as suggested by Peter, would then make a lot of
sense. Each CPU initfn would then look at that property and use it to
initialize (depending on the model) either SCTLR.B or SCTLR.EE.
The change to arm_cpu_memory_rw_debug for BE32 is also interesting. gdb
documentation says
The stub need not use any particular size or alignment when
gathering data from memory for the response; even if ADDR is
word-aligned and LENGTH is a multiple of the word size, the stub is
free to use byte accesses, or not.
while your change means that gdb actually wants you to do byte accesses.
Paolo
> 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.
