qemu-devel
[Top][All Lists]
Advanced

[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: Richard Henderson
Subject: Re: [Qemu-devel] RFC: Why does target/m68k RTE insn. use gen_exception
Date: Sat, 29 Jun 2019 12:15:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 6/28/19 5:50 PM, Lucien Murray-Pitts wrote:
>  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.

The way I read it from the 68040 manual, it's "the pc of the instruction
executing at the time the fault was detected".  Well, we did in fact detect the
fault at "retaddr", so that seems to be the right answer.  The fact that real
hardware has a different pipeline and detects the fault later seems immaterial,
and largely irrelevant, since the programmer wasn't given any guarantees for
what sort of value appears in that slot.

> 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);


For a device to raise a bus error, it should return MEMTX_ERROR (or something).
 This eventually reaches cpu_transaction_failed, which has all of the data that
you seem to be missing above.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]