qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] PowerPC code generation and the program counter


From: Alexander Graf
Subject: Re: [Qemu-devel] PowerPC code generation and the program counter
Date: Mon, 13 Sep 2010 09:53:00 +0200

On 13.09.2010, at 06:51, Stu Grossman wrote:

> I've been using qemu-12.4 to trace accesses to non-existent addresses, but 
> I've
> found that the PC is incorrect when cpu_abort() is called from within the
> unassigned memory helper routines (unassigned_mem_read[bwl] and
> unassigned_mem_write[bwl]).  Even nearby instructions (plus or minus 10
> instructions or so) don't match the type of load or store being done, so this
> isn't a PC being current_instr+4 kind of thing.
> 
> I ended up modifying the GEN_LD* and GEN_ST* macros (in 
> target-ppc/translate.c)
> to call gen_update_nip(ctx, ctx->nip - 4).  This fixed the above problem, 
> which
> has helped enormously.
> 
> Since I'm not a qemu expert, I was wondering about several things:
> 
>       1) Was it really necessary to add gen_update_nip to the load and store
>          instructions in order to get the correct PC?  Could the correct PC
>          have been derived some other way, without a runtime cost for all
>          basic loads and stores?
>       2) As the current code lacks that fix, the basic load and store
>          instructions will save an incorrect PC if an exception occurs.  If
>          so, how come nobody noticed this before?  I think that exceptions
>          would have srr0 pointing at the last instruction which called
>          gen_update_nip.  So when the target returns from a data exception,
>          it might re-execute some instructions.  Possibly harmless, but could
>          lead to subtle bugs...

Usually on a page fault, there is some tcg magic involved that tries to figure 
out which instruction inside the TB is responsible for the fault and sets pc 
accordingly.
Maybe that code path only gets involved when we generate a real page fault, so 
in your case you'd have to call the same on unassigned address accesses.


Alex




reply via email to

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