[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub suppor
Re: [Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub support.
Fri, 4 Nov 2016 10:25:16 +0000
On Fri, 4 Nov 2016 09:48:06 +0100
Paolo Bonzini <address@hidden> 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
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.
[Qemu-devel] [PATCH 3/5] Fix arm_semi_flen_cb for BE32 system mode., Julian Brown, 2016/11/03
[Qemu-devel] [PATCH 4/5] ARM BE32 watchpoint fix., Julian Brown, 2016/11/03
[Qemu-devel] [PATCH 5/5] Fix typo in arm_cpu_do_interrupt_aarch32., Julian Brown, 2016/11/03