>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 <crosthwaite.pe...@gmail.com>
---
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(-)
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);
--
1.9.1
