On Fri, Jun 28, 2019 at 11:35:48AM +0200, Richard Henderson wrote: > On 6/28/19 2:27 AM, Lucien Murray-Pitts wrote: > > > > [snip] ... 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...
This issue is to do with the stack frame generation storing the retaddr which is the current PC, I cant find any way to obtain the next PC when not inside the instructions (say a bus handler). So RTE will return to the instruction causing SIGSEGV op_helper.c static void m68k_interrupt_all(CPUM68KState *env, int is_hw) ... if (cs->exception_index == EXCP_ACCESS) { ... do_stack_frame(env, &sp, 7, oldsr, 0, retaddr /*LMP: BROKEN - needs PC NEXT*/); Actually according to the MC68000 manuals the "return address" (the PC saved on the stack) can be upto 5 instructions later due to prefetch. So some pc_next would best be used here. I am not clear how this should work in the presence of an MMU though. I am triggering this from inside my device by doing the following, since that memory address should dynamically cause a bus error (I hope this is the right way to do it) cpuclass->do_unassigned_access( s->cpu, /*addr*/0x0, /*is_write*/1, /*is_exec*/0, opaque, /*size*/4); Something similar with TRAP#0 / RTE combination will happen. Stepping on the TRAP#0 does correctly get me to the ISR, but a subsequent RTE will step me +1 past the return whilst a break point and run will land in the right place. I need to experiment a bit more with a solid setup. > > 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~ I see the function but in 4.0 its been mangled a bit more, so I will have to get back to you. Seems that the issue persists in 2.x so maybe this is something new. Cheers, Luc