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~
