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

[Lucien Murray-Pitts]

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