| Message ID | 20221010095346.1957-3-thunder.leizhen@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: Make the dumped instructions are consistent with the disassembled ones | expand |
On Mon, 10 Oct 2022 at 11:56, Zhen Lei <thunder.leizhen@huawei.com> wrote: > > 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> > --- > arch/arm/kernel/traps.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c > index 34aa80c09c508c1..50b00c9091f079d 100644 > --- a/arch/arm/kernel/traps.c > +++ b/arch/arm/kernel/traps.c > @@ -193,6 +193,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs) > bad = get_user(val, &((u32 __user *)addr)[i]); > } > > + if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8)) { > + if (thumb) > + val = (__force unsigned int)cpu_to_le16(val); Better use swab16() here instead of the ugly __force cast, given that the swab is going to occur unconditionally here. > + else > + val = (__force unsigned int)cpu_to_le32(val); and swab32() here > + } > + > if (!bad) > p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ", > width, val); > -- > 2.25.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 2022/10/10 18:10, Ard Biesheuvel wrote: > On Mon, 10 Oct 2022 at 11:56, Zhen Lei <thunder.leizhen@huawei.com> wrote: >> >> 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> >> --- >> arch/arm/kernel/traps.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c >> index 34aa80c09c508c1..50b00c9091f079d 100644 >> --- a/arch/arm/kernel/traps.c >> +++ b/arch/arm/kernel/traps.c >> @@ -193,6 +193,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs) >> bad = get_user(val, &((u32 __user *)addr)[i]); >> } >> >> + if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8)) { >> + if (thumb) >> + val = (__force unsigned int)cpu_to_le16(val); > > Better use swab16() here instead of the ugly __force cast, given that > the swab is going to occur unconditionally here. Good idea. > > >> + else >> + val = (__force unsigned int)cpu_to_le32(val); > > and swab32() here OK > > >> + } >> + >> if (!bad) >> p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ", >> width, val); >> -- >> 2.25.1 >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > . >
On Mon, 10 Oct 2022 at 12:46, Leizhen (ThunderTown) <thunder.leizhen@huawei.com> wrote: > > > > On 2022/10/10 18:10, Ard Biesheuvel wrote: > > On Mon, 10 Oct 2022 at 11:56, Zhen Lei <thunder.leizhen@huawei.com> wrote: > >> > >> 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> > >> --- > >> arch/arm/kernel/traps.c | 7 +++++++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c > >> index 34aa80c09c508c1..50b00c9091f079d 100644 > >> --- a/arch/arm/kernel/traps.c > >> +++ b/arch/arm/kernel/traps.c > >> @@ -193,6 +193,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs) > >> bad = get_user(val, &((u32 __user *)addr)[i]); > >> } > >> > >> + if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8)) { > >> + if (thumb) > >> + val = (__force unsigned int)cpu_to_le16(val); > > > > Better use swab16() here instead of the ugly __force cast, given that > > the swab is going to occur unconditionally here. > > Good idea. > > > > > > >> + else > >> + val = (__force unsigned int)cpu_to_le32(val); > > > > and swab32() here > > OK > Actually, come to think of it, should this code perhaps be using the mem_to_opcode helpers that are being used elsewhere in the file?
On 2022/10/10 19:07, Ard Biesheuvel wrote: > On Mon, 10 Oct 2022 at 12:46, Leizhen (ThunderTown) > <thunder.leizhen@huawei.com> wrote: >> >> >> >> On 2022/10/10 18:10, Ard Biesheuvel wrote: >>> On Mon, 10 Oct 2022 at 11:56, Zhen Lei <thunder.leizhen@huawei.com> wrote: >>>> >>>> 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> >>>> --- >>>> arch/arm/kernel/traps.c | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c >>>> index 34aa80c09c508c1..50b00c9091f079d 100644 >>>> --- a/arch/arm/kernel/traps.c >>>> +++ b/arch/arm/kernel/traps.c >>>> @@ -193,6 +193,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs) >>>> bad = get_user(val, &((u32 __user *)addr)[i]); >>>> } >>>> >>>> + if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8)) { >>>> + if (thumb) >>>> + val = (__force unsigned int)cpu_to_le16(val); >>> >>> Better use swab16() here instead of the ugly __force cast, given that >>> the swab is going to occur unconditionally here. >> >> Good idea. >> >>> >>> >>>> + else >>>> + val = (__force unsigned int)cpu_to_le32(val); >>> >>> and swab32() here >> >> OK >> > > Actually, come to think of it, should this code perhaps be using the > mem_to_opcode helpers that are being used elsewhere in the file? Right, __mem_to_opcode_xxx is the correct solution. I need to test it. > . >
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c index 34aa80c09c508c1..50b00c9091f079d 100644 --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -193,6 +193,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs) bad = get_user(val, &((u32 __user *)addr)[i]); } + if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8)) { + if (thumb) + val = (__force unsigned int)cpu_to_le16(val); + else + val = (__force unsigned int)cpu_to_le32(val); + } + if (!bad) p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ", width, val);
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> --- arch/arm/kernel/traps.c | 7 +++++++ 1 file changed, 7 insertions(+)