From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEP7S-0002z2-H9 for qemu-devel@nongnu.org; Wed, 19 Sep 2012 14:35:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEP7R-0004Q2-G2 for qemu-devel@nongnu.org; Wed, 19 Sep 2012 14:35:30 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:59237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEP7R-0003fc-9A for qemu-devel@nongnu.org; Wed, 19 Sep 2012 14:35:29 -0400 Received: by mail-pb0-f45.google.com with SMTP id rp12so3090844pbb.4 for ; Wed, 19 Sep 2012 11:35:28 -0700 (PDT) Sender: Richard Henderson Message-ID: <505A106D.8020009@twiddle.net> Date: Wed, 19 Sep 2012 11:35:25 -0700 From: Richard Henderson MIME-Version: 1.0 References: <5059FA36.1080301@twiddle.net> <505A011C.1020106@twiddle.net> <20120919175116.GC29951@hall.aurel32.net> <505A0895.8000008@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Shifts, ppc[64], xtensa List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Max Filippov , qemu-devel@nongnu.org, Aurelien Jarno On 09/19/2012 11:30 AM, Peter Maydell wrote: > On 19 September 2012 19:01, Richard Henderson 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~