[v2,05/18] arm: cpu: handle BE32 user-mode as BE

Commit Message

Peter Crosthwaite March 2, 2016, 6:56 a.m. UTC

From a system emulation point of view, BE32 is best modelled as little
endian with address manipulations on subword accesses (to give the
illusion of BE). But user-mode cannot tell the difference and is
already implemented as straight BE. So handle the difference in the
endianess query, where USER mode is BE and system is not.

Signed-off-by: Peter Crosthwaite <[e-mail]>
---
Changed since v1:
Rewrote commit subject and message formerly:
    arm: linux-user: don't set CPSR.E in BE32 mode

 target-arm/cpu.h | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

Patch

diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 75e5ea0..ab0ea92 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -1915,7 +1915,22 @@  static inline bool arm_cpu_data_is_big_endian(CPUARMState *env)
 
     /* In 32bit endianness is determined by looking at CPSR's E bit */
     if (!is_a64(env)) {
-        return (env->uncached_cpsr & CPSR_E) ? 1 : 0;
+        return
+#ifdef CONFIG_USER_ONLY
+            /* In system mode, BE32 is modelled in line with the
+             * architecture (as word-invariant big-endianness), where loads
+             * and stores are done little endian but from addresses which
+             * are adjusted by XORing with the appropriate constant. So the
+             * endianness to use for the raw data access is not affected by
+             * SCTLR.B.
+             * In user mode, however, we model BE32 as byte-invariant
+             * big-endianness (because user-only code cannot tell the
+             * difference), and so we need to use a data access endianness
+             * that depends on SCTLR.B.
+             */
+            arm_sctlr_b(env) ||
+#endif
+                ((env->uncached_cpsr & CPSR_E) ? 1 : 0);
     }
 
     cur_el = arm_current_el(env);