Re: [Qemu-devel] [PATCH v2 4/8] linux-user: arm: handle CPSR.E correctly in strex emulation

[Peter Maydell]

On 3 June 2014 10:23, Paolo Bonzini <address@hidden> wrote:
> Il 02/06/2014 18:17, Peter Maydell ha scritto:
>
>> Um. This feels like we're wrongly overloading this flag for
>> more than one thing. "Is the user-mode binary BE8?" is
>> definitely not a property of the CPU, so it shouldn't be
>> a CPU state flag. (Conversely, "is the iside endianness the
>> opposite way round to TARGET_WORDS_BIGENDIAN" is a CPU
>> property of sorts.) It seems to me that we probably want
>> to fix this by more correctly modelling the actual CPU
>> state involved here, by having user-mode either set or
>> not set SCTLR.B [set only if BE32 binary], and the data
>> and insn fetches honour both that and CPSR.E appropriately.)
>
>
> So basically it's s/bswap_code/!sctlr_b/.  Thanks for the suggestion!

Actually I was thinking again about this last night, and
user-mode is a bit odd, since it's the only place we
ever have TARGET_WORDS_BIGENDIAN set.

System emulation: TARGET_WORDS_BIGENDIAN indicates the
"bus endianness", always LE for ARM.
User emulation: TARGET_WORDS_BIGENDIAN indicates the
"kernel API endianness", so may be BE or LE.

In system emulation it's clear how we should implement
things: TARGET_WORDS_BIGENDIAN is never set, data
accesses honour CPSR.E by doing MO_BE or MO_LE accesses,
instruction accesses are always MO_LE, and SCTLR.B
is implemented by XORing the address with 3 (for
byte accesses) or 1 (for halfword accesses).
[SCTLR.B is word-invariant big-endian, hence the need
to use XORs. In practice since there's not much interest
in system emulation of BE32 we can leave it unimplemented.]

In user emulation, things are more complicated for BE32,
because we're sort of emulating the word-invariant
bigendian using byte-invariant big-endian (this is
safe because there's no way for a userspace program
to get at anything that would let it tell the
difference). So we can't just say "set SCTLR.B
and handle as if SCTLR.B is set in the way system
emulation would", because the behaviour has to
be different.

So in summary I'm not sure of the right approach
any more...

thanks
-- PMM