From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCzpC-0006fE-2S for qemu-devel@nongnu.org; Thu, 21 Apr 2011 15:46:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QCzpB-0007kN-0g for qemu-devel@nongnu.org; Thu, 21 Apr 2011 15:46:01 -0400 Received: from mail-ey0-f173.google.com ([209.85.215.173]:64944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCzpA-0007k1-R9 for qemu-devel@nongnu.org; Thu, 21 Apr 2011 15:46:00 -0400 Received: by eyb6 with SMTP id 6so20576eyb.4 for ; Thu, 21 Apr 2011 12:45:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20110410132415.GA6719@volta.aurel32.net> Date: Thu, 21 Apr 2011 23:45:58 +0400 Message-ID: From: Igor Kovalenko Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Desnogues Cc: Blue Swirl , peter.maydell@linaro.org, Aurelien Jarno , qemu-devel , Artyom Tarasenko On Thu, Apr 21, 2011 at 7:44 PM, Laurent Desnogues wrote: > On Thu, Apr 21, 2011 at 4:57 PM, Artyom Tarasenko wrote: >> On Tue, Apr 12, 2011 at 4:14 AM, Igor Kovalenko >> wrote: >>>>> Do you have public test case? >>>>> It is possible to code this delay slot write test but real issue may >>>>> be corruption elsewhere. >> >> The test case is trivial: it's just the two instructions, branch and wrpr. >> >>> In theory there could be multiple issues including compiler induced ones. >>> I'd prefer to see some kind of reproducible testcase. >> >> Ok, attached a 40 byte long test (the first 32 bytes are not used and >> needed only because the bios entry point is 0x20). >> >> $ git pull && make && sparc64-softmmu/qemu-system-sparc64 -bios >> test-wrpr.bin -nographic >> Already up-to-date. >> make[1]: Nothing to be done for `all'. >> /mnt/terra/projects/vanilla/qemu/tcg/tcg.c:1892: tcg fatal error >> Aborted > > The problem seems to be that wrpr is using a non-local > TCG tmp (cpu_tmp0). Just tried the test case with write to %pil - seems like write itself is OK. The issue appears to be with save_state() call since adding save_state to %pil case provokes the same tcg abort. -- Kind regards, Igor V. Kovalenko