Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception

[Richard Henderson <richard.henderson@linaro.org>]

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~