On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar <abhijeetinamdar3...@gmail.com> wrote: > How do I fix it ? it's for cortex-m3 and the below is the gdb trace when I > load ELF. > > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > R00=00000000 R01=00000000 R02=00000000 R03=00000000 > R04=00000000 R05=00000000 R06=00000000 R07=00000000 > R08=00000000 R09=00000000 R10=00000000 R11=00000000 > R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000 > XPSR=40000003 -Z-- A handler > FPSCR: 00000000
If the CPU goes into Lockup this indicates that something has gone very badly wrong with your guest code, and the situation is not recoverable. In real hardware the CPU sits there doing absolutely nothing forever more[*]. QEMU doesn't actually emulate the CPU being in Lockup state, so it just treats it as a fatal error. (Check the M-profile architecture reference for more information on Lockup and the various kinds of guest bug that can get you there.) This particular case is "we needed to take a HardFault exception, but we were already in a HardFault exception". The most common cause of this is that your code has crashed hard on startup (eg it tries to read from unreadable memory or jumps off into nowhere: if this happens before it has set up exception handling for HardFault then you get this. This also happens if its attempt to handle HardFaults is buggy and crashes.) You should approach this by debugging your guest and looking at what it is doing before it gets to this point. [*] Technically there are ways to get yourself out of Lockup state on a real CPU, such as having an external watchdog that resets the CPU, or some extremely esoteric tricks used only by code that's trying to test how Lockup state behaves. -- PMM