[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception
From: |
Lucien Murray-Pitts |
Subject: |
Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception |
Date: |
Sat, 29 Jun 2019 00:50:30 +0900 |
User-agent: |
Mutt/1.12.0 (2019-05-25) |
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
- [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception, Lucien Anti-Spam, 2019/06/27
- Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception, Lucien Anti-Spam, 2019/06/27
- Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception, Richard Henderson, 2019/06/27
- Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception, Lucien Murray-Pitts, 2019/06/27
- Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception, Richard Henderson, 2019/06/28
- Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception,
Lucien Murray-Pitts <=
- Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception, Richard Henderson, 2019/06/29
- Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception, Lucien Murray-Pitts, 2019/06/29
- Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception, Richard Henderson, 2019/06/30