From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgohR-0004iv-IJ for qemu-devel@nongnu.org; Mon, 18 Jun 2012 23:01:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SgohP-0002Fi-TO for qemu-devel@nongnu.org; Mon, 18 Jun 2012 23:01:49 -0400 Received: from ch1ehsobe004.messaging.microsoft.com ([216.32.181.184]:48182 helo=ch1outboundpool.messaging.microsoft.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgohP-0002Fa-Om for qemu-devel@nongnu.org; Mon, 18 Jun 2012 23:01:47 -0400 Date: Mon, 18 Jun 2012 21:31:36 -0500 From: Scott Wood Message-ID: <20120619023136.GA5187@tyr.buserror.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Subject: [Qemu-devel] [PATCH] tci: don't write zero for reloc in tci_out_label List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel@nongnu.org If tci_out_label is called in the context of tcg_gen_code_search_pc, we could be overwriting an already patched relocation with zero -- and not repatch it because the set_label is past search_pc, causing a QEMU crash when it tries to branch to a zero label. Not writing anything to the relocation area seems to be in line with what other backends do from the couple I looked at (x86, ppc). Signed-off-by: Scott Wood --- tcg/tci/tcg-target.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tcg/tci/tcg-target.c b/tcg/tci/tcg-target.c index 453f187..3c6b0f5 100644 --- a/tcg/tci/tcg-target.c +++ b/tcg/tci/tcg-target.c @@ -487,7 +487,7 @@ static void tci_out_label(TCGContext *s, TCGArg arg) assert(label->u.value); } else { tcg_out_reloc(s, s->code_ptr, sizeof(tcg_target_ulong), arg, 0); - tcg_out_i(s, 0); + s->code_ptr += sizeof(tcg_target_ulong); } } -- 1.7.5.4