From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LM6f6-0003SH-J5 for qemu-devel@nongnu.org; Sun, 11 Jan 2009 15:11:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LM6f3-0003PU-VG for qemu-devel@nongnu.org; Sun, 11 Jan 2009 15:11:56 -0500 Received: from [199.232.76.173] (port=60675 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LM6f3-0003PK-Pd for qemu-devel@nongnu.org; Sun, 11 Jan 2009 15:11:53 -0500 Received: from amistad.itbs.cz ([81.0.238.226]:35709) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LM6f3-0000JZ-Ah for qemu-devel@nongnu.org; Sun, 11 Jan 2009 15:11:53 -0500 Message-ID: <496A5283.3080705@jermar.eu> Date: Sun, 11 Jan 2009 21:11:47 +0100 From: Jakub Jermar MIME-Version: 1.0 References: <496A2BE4.9040504@jermar.eu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [BUG] Possible bug in sparc64 emulation of SAVE/RESTORE Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org Blue Swirl wrote: > On 1/11/09, Jakub Jermar wrote: >> Hi, >> >> I've just noticed that functions: >> >> helper_save() >> helper_restore() >> cpu_cwp_inc() >> cpu_cwp_dec >> >> assume that CWP moves counter-clock-wise on sparc64. >> I am pretty sure it moves clock-wise on sparc64 >> (contrary to the situation on sparc32). > > True, but internally we use V8 way to make register window handling > simpler. Outside world should see CWP acting as specified. > > There is a comment about this somewhere, maybe it is unclear. Aha, so it is me who was actually confused :-) I am tracking some kind of a corruption: GDB loses control on the RETRY instruction of the fill_0_normal_tl0 handler. QEMU continues to execute and ends up in Error state. qemu: fatal: Trap 0x0008 while trap level (5) >= MAXTL (5), Error state pc: 000000000040c100 npc: 000000000040c104 General Registers: %g0: 0000000000000000 %g1: 0000000000000000 %g2: 0000000000000000 %g3: 0000000000000000 %g4: 0000000000000000 %g5: 0000000000000000 %g6: 0000000000000000 %g7: 0000000000000000 Current Register Window: %o0: 0000000000000046 %o1: 0000000000717dc0 %o2: 0000000000717f50 %o3: 0000000000000000 %o4: 000000000000000a %o5: 0000000000717cff %o6: 0000000000717521 %o7: 0000000000432198 %l0: 0000000000000004 %l1: 000000000005c980 %l2: 000000000043d888 %l3: 000000000005c000 %l4: 0000000000000001 %l5: 000000000043e5f8 %l6: 0000000000000001 %l7: 000000000045e368 %i0: 000000000005c980 %i1: 0000000000000000 %i2: 0000000000000000 %i3: 000000000042d120 %i4: 000000000042d100 %i5: 0000000000000005 %i6: 00000000007175f1 %i7: 0000000000421db8 Floating Point Registers: %f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 %f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000 pstate: 0x00000414 ccr: 0x00 asi: 0x58 tl: 5 fprs: 0 cansave: 4 canrestore: 2 otherwin: 0 wstate 0 cleanwin 7 cwp 2 fsr: 0x00000000 Aborted The interesting thing is that GDB doesn't break into the debugger when it starts executing the function which has its address in pc (i.e. instruction_access_exception_tl1), even though I set a breakpoint for it. (I set breakpoints for all MMU-related traps, but didn't hit any). Jakub