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

[Julian Brown <julian@codesourcery.com>]

On Fri, 4 Nov 2016 09:48:06 +0100
Paolo Bonzini <pbonzini@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