On 23 August 2018 at 17:36, Christopher Friedt <chrisfri...@gmail.com> wrote: > I hope this message finds you well, as I'm currently on a lake in the > middle of nowhere relying on my flaky cellular connection. Roaming > sucks. In any case, I found a bug while trying to execute the "svc 0" > instruction for cortex-m3. > > A UsageFault (EXCP_INVSTATE) is injected at > target/arm/translate.c:disas_arm_insn() without the patch. I noticed > because I added a log statement to the effect, so my pre-patch output > was: > > $ qemu-system-arm -d int -M netduino2 -cpu cortex-m3 -S -s > -semihosting -nographic -kernel hello.bin > Taking exception 2 [SVC] > ... as 11 > M variants do not implement ARM mode. > Taking exception 18 [v7M INVSTATE UsageFault] > ... as 3 > M variants do not implement ARM mode. > Taking exception 18 [v7M INVSTATE UsageFault] > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > R00=2000079c R01=0000008c R02=00000000 R03=000f0005 > R04=2000071c R05=20000808 R06=00000000 R07=000f0005 > R08=00000000 R09=00000000 R10=00000000 R11=00000000 > R12=00000000 R13=200018e0 R14=fffffff1 R15=00000000 > XPSR=00000003 ---- A handler > FPSCR: 00000000 > Abort trap: 6
Hi; thanks for your patch, but I don't think it is correct. What it does is to make QEMU ignore the T bit in the xPSR. The architecture says that what should happen is that attempts to execute with the T bit clear should cause an INVSTATE UsageFault, which is exactly what we do. The reason we end up aborting is because the CPU should really be going into Lockup mode (where it basically hangs indefinitely), and QEMU doesn't implement that. Your guest code almost certainly has a bug where it is not setting the low bit in the words in its exception vector table. See the v7M ARM ARM section B1.5.3 if you happen to have a copy on your lake, but the short answer is that bit 1 must be set, exactly because this is what defines whether EPSR.T is set on exception entry. If you tried this on real hardware it would fail in the same way (except that the hardware would lock up and sit there like a lemon rather than calling abort()). thanks -- PMM