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

[Lucien Murray-Pitts]

On Mon, Jul 1, 2019 at 9:11 PM Peter Maydell <address@hidden>
wrote:

> > On Mon, 1 Jul 2019 at 13:04, Lucien Anti-Spam
> > <address@hidden> wrote:
> > > Further to my initial problem I noticed that TRAP #0 also jumps to the
> handlers +1 instruction.
> > > Same behavior can also be seen with ARM "SWI #0".    (PC shows 0x0C vs
> the expected 0x08)
> >
> > Yes, that's a known bug for arm -- we treat "single step" as
> > "execute one instruction", whereas I think most debuggers will
> > treat "we took an exception" as a reason to stop the single step
> > and return control to the user, rather than executing the insn at
> > the exception entry point as the one instruction of the step.
> > (You can see similar odd behaviour if you try to single step a
> > load instruction which causes a data abort, for instance -- on
> > arm at least we will execute the first insn of the data abort
> > handler before completing the step.)
> > thanks
> > -- PMM
>

As recommended in the previous email this is fixable with a call to handle
debug
when were in single step -  I will submit that patch if nobody else it
working on this?

I also then found the m68k stack frame is fouled for 68010/68020 (wrong
frame type,
and it does not honor the special status word aka SSW).

In real hardware the handler code should alter the stack frame chaning the
SSW.
RTE should then start/or-not-start the "pipeline" again from the setting in
the SSW.
This allows for stage B/C stage re-runs, thus a retry on the read
instruction.
I suspect it will keep looping, and retrying until the exception handler
decides to turn
off the rerun.

I am thinking the easiest method would be to check the re-run bits in the
SSW and
jump back to next_pc instead of pc inside the RTE instruction handler.

Any suggestions on how to obtain pc_next from the "m68k_cpu_do_interrupt(
CPUState *cs)" ?

What do we think of this approach?

Cheers,
Luc