* Re: [PATCH v5 17/31] target/arm: Enforce alignment for LDM/STM [not found] ` <20210419202257.161730-18-richard.henderson@linaro.org> @ 2021-08-31 0:51 ` Nathan Chancellor 2021-09-07 13:44 ` Richard Henderson 0 siblings, 1 reply; 3+ messages in thread From: Nathan Chancellor @ 2021-08-31 0:51 UTC (permalink / raw) To: Richard Henderson; +Cc: qemu-devel, Peter Maydell, qemu-arm, llvm Hi Richard, On Mon, Apr 19, 2021 at 01:22:43PM -0700, Richard Henderson wrote: > Reviewed-by: Peter Maydell <peter.maydell@linaro.org> > Signed-off-by: Richard Henderson <richard.henderson@linaro.org> > --- > target/arm/translate.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/target/arm/translate.c b/target/arm/translate.c > index 29fbbb84b2..f58ac4f018 100644 > --- a/target/arm/translate.c > +++ b/target/arm/translate.c > @@ -7868,7 +7868,7 @@ static bool op_stm(DisasContext *s, arg_ldst_block *a, int min_n) > } else { > tmp = load_reg(s, i); > } > - gen_aa32_st32(s, tmp, addr, mem_idx); > + gen_aa32_st_i32(s, tmp, addr, mem_idx, MO_UL | MO_ALIGN); > tcg_temp_free_i32(tmp); > > /* No need to add after the last transfer. */ > @@ -7943,7 +7943,7 @@ static bool do_ldm(DisasContext *s, arg_ldst_block *a, int min_n) > } > > tmp = tcg_temp_new_i32(); > - gen_aa32_ld32u(s, tmp, addr, mem_idx); > + gen_aa32_ld_i32(s, tmp, addr, mem_idx, MO_UL | MO_ALIGN); > if (user) { > tmp2 = tcg_const_i32(i); > gen_helper_set_user_reg(cpu_env, tmp2, tmp); > -- > 2.25.1 I just bisected a boot hang with an LLVM-built multi_v7_defconfig + CONFIG_THUMB2_KERNEL=y kernel down to this commit. I do not see the same hang when the kernel is compiled with GCC 11.2.0 and binutils 2.37 nor do I see a hang with multi_v7_defconfig by itself. Is there something that LLVM is doing wrong when compiling/assembling/linking the kernel or is there something wrong/too aggressive with this commit? I can reproduce this with current QEMU HEAD (ad22d05833). My QEMU invocation is: $ qemu-system-arm \ -append "console=ttyAMA0 earlycon" \ -display none \ -initrd rootfs.cpio \ -kernel zImage \ -M virt \ -m 512m \ -nodefaults \ -no-reboot \ -serial mon:stdio and the rootfs.cpio and zImage files can be found here: https://github.com/nathanchance/bug-files/tree/15c1fd6e44622a3c27823d2c5c3083dfc7246146/qemu-2e1f39e29bf9a6b28eaee9fc0949aab50dbad94a Cheers, Nathan ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v5 17/31] target/arm: Enforce alignment for LDM/STM 2021-08-31 0:51 ` [PATCH v5 17/31] target/arm: Enforce alignment for LDM/STM Nathan Chancellor @ 2021-09-07 13:44 ` Richard Henderson 2021-09-15 1:13 ` Nick Desaulniers 0 siblings, 1 reply; 3+ messages in thread From: Richard Henderson @ 2021-09-07 13:44 UTC (permalink / raw) To: Nathan Chancellor; +Cc: qemu-devel, Peter Maydell, qemu-arm, llvm On 8/31/21 2:51 AM, Nathan Chancellor wrote: > I just bisected a boot hang with an LLVM-built multi_v7_defconfig + > CONFIG_THUMB2_KERNEL=y kernel down to this commit. I do not see the same > hang when the kernel is compiled with GCC 11.2.0 and binutils 2.37 nor > do I see a hang with multi_v7_defconfig by itself. Is there something > that LLVM is doing wrong when compiling/assembling/linking the kernel or > is there something wrong/too aggressive with this commit? I can > reproduce this with current QEMU HEAD (ad22d05833). > > My QEMU invocation is: > > $ qemu-system-arm \ > -append "console=ttyAMA0 earlycon" \ > -display none \ > -initrd rootfs.cpio \ > -kernel zImage \ > -M virt \ > -m 512m \ > -nodefaults \ > -no-reboot \ > -serial mon:stdio > > and the rootfs.cpio and zImage files can be found here: > > https://github.com/nathanchance/bug-files/tree/15c1fd6e44622a3c27823d2c5c3083dfc7246146/qemu-2e1f39e29bf9a6b28eaee9fc0949aab50dbad94a Hmm. I see IN: 0xc13038e2: e890 008c ldm.w r0, {r2, r3, r7} R00=c13077ca R01=c11a8058 R02=c11a8058 R03=c031737f R04=48379000 R05=00000024 R06=c031748d R07=c03174bb R08=412fc0f1 R09=c0ce9308 R10=50c5387d R11=00000000 R12=00000009 R13=c1501f88 R14=c0301739 R15=c13038e2 PSR=200001f3 --C- T svc32 Taking exception 4 [Data Abort] ...from EL1 to EL1 ...with ESR 0x25/0x9600003f ...with DFSR 0x1 DFAR 0xc13077ca So, yes, it's a ldm from an address % 4 = 2, so it is correct that we should trap. You should see the same trap on real hw. r~ ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v5 17/31] target/arm: Enforce alignment for LDM/STM 2021-09-07 13:44 ` Richard Henderson @ 2021-09-15 1:13 ` Nick Desaulniers 0 siblings, 0 replies; 3+ messages in thread From: Nick Desaulniers @ 2021-09-15 1:13 UTC (permalink / raw) To: Richard Henderson, Nathan Chancellor Cc: qemu-devel, Peter Maydell, qemu-arm, llvm On Tue, Sep 7, 2021 at 6:44 AM Richard Henderson <richard.henderson@linaro.org> wrote: > > On 8/31/21 2:51 AM, Nathan Chancellor wrote: > > I just bisected a boot hang with an LLVM-built multi_v7_defconfig + > > CONFIG_THUMB2_KERNEL=y kernel down to this commit. I do not see the same > > hang when the kernel is compiled with GCC 11.2.0 and binutils 2.37 nor > > do I see a hang with multi_v7_defconfig by itself. Is there something > > that LLVM is doing wrong when compiling/assembling/linking the kernel or > > is there something wrong/too aggressive with this commit? I can > > reproduce this with current QEMU HEAD (ad22d05833). > > > > My QEMU invocation is: > > > > $ qemu-system-arm \ > > -append "console=ttyAMA0 earlycon" \ > > -display none \ > > -initrd rootfs.cpio \ > > -kernel zImage \ > > -M virt \ > > -m 512m \ > > -nodefaults \ > > -no-reboot \ > > -serial mon:stdio > > > > and the rootfs.cpio and zImage files can be found here: > > > > https://github.com/nathanchance/bug-files/tree/15c1fd6e44622a3c27823d2c5c3083dfc7246146/qemu-2e1f39e29bf9a6b28eaee9fc0949aab50dbad94a > > Hmm. I see > > IN: > 0xc13038e2: e890 008c ldm.w r0, {r2, r3, r7} > > R00=c13077ca R01=c11a8058 R02=c11a8058 R03=c031737f > R04=48379000 R05=00000024 R06=c031748d R07=c03174bb > R08=412fc0f1 R09=c0ce9308 R10=50c5387d R11=00000000 > R12=00000009 R13=c1501f88 R14=c0301739 R15=c13038e2 > PSR=200001f3 --C- T svc32 > Taking exception 4 [Data Abort] > ...from EL1 to EL1 > ...with ESR 0x25/0x9600003f > ...with DFSR 0x1 DFAR 0xc13077ca > > So, yes, it's a ldm from an address % 4 = 2, so it is correct that we should trap. You > should see the same trap on real hw. Makes sense. I guess if we can find which label that's in, we can look closer into the code generated by the compiler. scripts/extract-vmlinux doesn't seem to be able to extract a vmlinux from either zImage artifact though; not sure yet we'll be able to disassemble those. Oh, I guess GDB can show us. Looks like 0xc13038e2 is...hard to tell, there's no debug info so we just have jumps to addresses in hex, not symbols. I don't know my way around GDB well enough to get a sense for where we are in the source code. https://gist.github.com/nickdesaulniers/764ac9afab04775846ffa6c90c5a266a If I rebuild QEMU from source, I don't get any disassembly that looks similar, probably as a result of different compiler versions, and maybe adding debug info. -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-09-15 1:13 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20210419202257.161730-1-richard.henderson@linaro.org> [not found] ` <20210419202257.161730-18-richard.henderson@linaro.org> 2021-08-31 0:51 ` [PATCH v5 17/31] target/arm: Enforce alignment for LDM/STM Nathan Chancellor 2021-09-07 13:44 ` Richard Henderson 2021-09-15 1:13 ` Nick Desaulniers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).