On Fri, 4 Nov 2016 09:48:06 +0100 Paolo Bonzini <pbonz...@redhat.com> wrote:
> 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? Yes, exactly. I think we more-or-less just added a armeb-softmmu.mak and things worked -- at least as far as BE32 mode, and bearing in mind that we were only interested in instruction-set simulation. BE8 mode is (ahem) a different matter, i.e. we (as in Mentor) might just have been getting that wrong. Oops! > 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. OK, that makes sense, thanks. > 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. The splitting-into-bytes is just an implementation convenience -- the simplest way I could see of handling the low-order address bit reversal without breaking abstractions more or shuffling lots of code around. I'm not sure if GDB was actually requesting sub-word access sizes. Thanks, Julian