On 6/28/19 2:27 AM, Lucien Murray-Pitts wrote: > The original way of handling it was causing single step to malfunction, I dont > rightly know why but the effect was that step would step twice and end up > inside the ISR function again OR just stepping past the RTE as if it didnt > exist. > > I have made a quick hack to implement it the way you suggest and confirm that > works better. > > HOWEVER, the "return" address is the instruction that causes the exception. > So it immediately does return to the ISR. > > This is a different issue, but I think interrelated to the original problem.
Is this a synchronous exception, like a SIGSEGV, that the instruction is causing? I have made attempts at fixing asynchronous interrupts, like the clock, in the presence of single-stepping. I haven't tested that in a while and I hope it's still working... > Further single stepping INTO the failing instruction results in ending up > at the ISR +1 instruction For a synchronous exception, that sounds like a real bug. Probably within cpu_handle_exception, #else if (replay_exception()) { CPUClass *cc = CPU_GET_CLASS(cpu); qemu_mutex_lock_iothread(); cc->do_interrupt(cpu); qemu_mutex_unlock_iothread(); + /* Single-step into the exception handler. */ + if (cpu->singlestep_enabled) { + cpu_handle_debug_exception(cpu); + } cpu->exception_index = -1; } else if (!replay_has_interrupt()) { r~