qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Shifts, ppc[64], xtensa


From: Richard Henderson
Subject: Re: [Qemu-devel] Shifts, ppc[64], xtensa
Date: Wed, 19 Sep 2012 11:35:25 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0

On 09/19/2012 11:30 AM, Peter Maydell wrote:
> On 19 September 2012 19:01, Richard Henderson <address@hidden> wrote:
>> On 09/19/2012 10:51 AM, Aurelien Jarno wrote:
>>> That said it is not a valid reason to not keep the value during
>>> re-translation, as it means the TB will exit instead of linking to
>>> the next one. The consequences are only the performance.
>>
>> We still have the problem of when is the goto_tb link initialized the 
>> *first* time?
>> Where we expect the goto_tb to fall through to stuff+exit_tb?
>>
>> For i386 it's during translation, with no care for re-translation.
>>
>> For ARM?  I can't see that it is.
> 
> I think the answer to this is that the only caller of cpu_gen_code()
> is tb_gen_code(), which always then calls tb_link_page()
> which calls tb_reset_jump() which calls tb_set_jmp_target().

That looks correct.  If convoluted.  ;-)

>> For PPC, malc has already verified that it *never* happens.  If he
>> puts "trap" insns there instead of "nop" insns, he'll see the trap.
> 
> ...but on the other hand that ought to work for PPC too, so
> presumably my analysis is wrong somewhere.

malc?  Breakpoint on ppc_tb_set_jmp_target?


r~




reply via email to

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