In ARM, the mapping of instruction memory is always little-endian, except
some BE-32 supported ARM architectures. Such as ARMv7-R, its instruction
endianness may be BE-32. Of course, its data endianness will also be BE-32
mode. Due to two negatives make a positive, the instruction stored in the
register after reading is in little-endian format. But for the case of
BE-8, the instruction endianness is LE, the instruction stored in the
register after reading is in big-endian format, which is inconsistent
with the disassembled one.
For example:
The content of disassembly:
c0429ee8:
e3500000 cmp r0, #0
c0429eec:
159f2044 ldrne r2, [pc, #68]
c0429ef0:
108f2002 addne r2, pc, r2
c0429ef4:
1882000a stmne r2, {r1, r3}
c0429ef8:
e7f000f0 udf #0
The output of undefined instruction exception:
Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
... ...
Code:
000050e3 44209f15 02208f10 0a008218 (
f000f0e7)
This inconveniences the checking of instructions. What's worse is that,
for somebody who don't know about this, might think the instructions are
all broken.
So, when CONFIG_CPU_ENDIAN_BE8=y, let's convert the instructions to
little-endian format before they are printed. The conversion result is
as follows:
Code:
e3500000 159f2044 108f2002 1882000a (
e7f000f0)
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
else
bad = get_kernel_nofault(tmp, &((u16 *)addr)[i]);
- val = tmp;
+ val = __mem_to_opcode_thumb16(tmp);
} else {
if (user_mode(regs))
bad = get_user(val, &((u32 __user *)addr)[i]);
else
bad = get_kernel_nofault(val, &((u32 *)addr)[i]);
+
+ val = __mem_to_opcode_arm(val);
}
if (!bad)