From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGseE-0001as-KI for qemu-devel@nongnu.org; Thu, 29 Jan 2015 12:12:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGse9-0000g8-Et for qemu-devel@nongnu.org; Thu, 29 Jan 2015 12:12:54 -0500 Received: from mail-qg0-x234.google.com ([2607:f8b0:400d:c04::234]:48932) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGse9-0000fW-9E for qemu-devel@nongnu.org; Thu, 29 Jan 2015 12:12:49 -0500 Received: by mail-qg0-f52.google.com with SMTP id z107so31067466qgd.11 for ; Thu, 29 Jan 2015 09:12:48 -0800 (PST) Sender: Richard Henderson Message-ID: <54CA6A0C.4040008@twiddle.net> Date: Thu, 29 Jan 2015 09:12:44 -0800 From: Richard Henderson MIME-Version: 1.0 References: <1400171983-6015-1-git-send-email-rth@twiddle.net> <1400171983-6015-6-git-send-email-rth@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 05/11] tcg-s390: Move ldst helpers out of line List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org On 01/29/2015 08:01 AM, Alexander Graf wrote: >> -static void tcg_finish_qemu_ldst(TCGContext* s, tcg_insn_unit *label2_ptr) >> +static void tcg_out_qemu_st_slow_path(TCGContext *s, TCGLabelQemuLdst *lb) >> { >> - /* patch branch */ >> - label2_ptr[1] = s->code_ptr - label2_ptr; >> + TCGReg addr_reg = lb->addrlo_reg; >> + TCGReg data_reg = lb->datalo_reg; >> + TCGMemOp opc = lb->opc; >> + >> + patch_reloc(lb->label_ptr[0], R_390_PC16DBL, (intptr_t)s->code_ptr, -2); > > Under certain situations this seems to create a jump to itself: > > (gdb) > 0x000000009082a3f0 in code_gen_buffer () > 1: x/i $pc > => 0x9082a3f0 : > jlh 0x9082a3f0 > > Any idea why exactly this would happen? Or do we endless loop on purpose? ;) You mean we actually arrive at this patch_reloc in that case? Jump-to-self is, if I'm not mistaken, the uninitialized state before we arrive here to output the slow path. I would have expected this symptom to indicate that we *hadn't* patched a jump rather than the reverse. My first guess is that there's some sort of data corruption going on. r~