From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J04Qp-0000tc-RZ for qemu-devel@nongnu.org; Wed, 05 Dec 2007 19:17:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J04Qp-0000rd-0P for qemu-devel@nongnu.org; Wed, 05 Dec 2007 19:17:35 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J04Qo-0000rE-Ks for qemu-devel@nongnu.org; Wed, 05 Dec 2007 19:17:34 -0500 Received: from eth6155.nsw.adsl.internode.on.net ([59.167.247.10] helo=sac.g2microsystems.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J04Qn-0006rJ-PT for qemu-devel@nongnu.org; Wed, 05 Dec 2007 19:17:34 -0500 Received: from [10.1.2.66] (badge.au.g2.internal [10.1.2.66]) by sac.g2microsystems.com (8.12.11.20060308/8.12.11) with ESMTP id lB60HPAY028519 for ; Thu, 6 Dec 2007 11:17:25 +1100 Message-ID: <47573F99.4060001@shaddybaddah.name> Date: Thu, 06 Dec 2007 11:17:29 +1100 From: Shaddy Baddah MIME-Version: 1.0 Subject: Re: [Qemu-devel] and now bus error for i386 guest References: <473A9DED.6020308@shaddybaddah.name> <473AAD7F.30709@shaddybaddah.name> <473AF480.6030802@shaddybaddah.name> <475554E1.5070509@shaddybaddah.name> <4756B6C9.3080507@shaddybaddah.name> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, Blue Swirl wrote: > On 12/5/07, Shaddy Baddah wrote: >> 0x1e958 : ld [ %l6 + 0x8c ], %l1 >> 0x1e95c : call 0xa90b4 >> 0x1e960 : mov %l1, %o0 > > Maybe you missed the effect of the delay slot. The first argument is > prepared in %l1 and moved to %o0 in the delay slot of the call > instruction. You'll have to forgive me... although I know about the delay slot, I only slightly dabble in assembly, so I am not so confident at reading it. Reading this to mean that perhaps the assignment would be effected after execution of a further instruction, I've redone the debugging, and include it below: $ gdb --args ./i386-softmmu/qemu -cdrom ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios GNU gdb 6.6.90.20070912-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) (gdb) break vl.c:7362 Breakpoint 1 at 0x1e958: file /home/shaddy/qemu-cvs/qemu/vl.c, line 7362. (gdb) display /i $pc (gdb) run Starting program: /home/shaddy/qemu-cvs/qemu-optbuild/i386-softmmu/qemu -cdrom ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios [Thread debugging using libthread_db enabled] [New Thread 0xf7f27550 (LWP 15523)] [Switching to Thread 0xf7f27550 (LWP 15523)] Breakpoint 1, main (argc=1430528, argv=0x15d400) at /home/shaddy/qemu-cvs/qemu/vl.c:7362 7362 env = next_cpu; 1: x/i $pc 0x1e958 : ld [ %l6 + 0x8c ], %l1 (gdb) print /x env $1 = 0x322e3100 (gdb) print /x next_cpu $2 = 0x1cd13e8 (gdb) stepi 7366 ret = cpu_exec(env); 1: x/i $pc 0x1e95c : call 0xa90b4 0x1e960 : mov %l1, %o0 (gdb) 0x0001e960 7366 ret = cpu_exec(env); 1: x/i $pc 0x1e960 : mov %l1, %o0 (gdb) print /x next_cpu $3 = 0x1cd13e8 (gdb) print /x env $4 = 0x322e3100 (gdb) print /x &env Address requested for identifier "env" which is in register $g6 (gdb) print $g6 $5 = 841888000 (gdb) print /x $g6 $6 = 0x322e3100 (gdb) stepi cpu_x86_exec (env1=0x117000) at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:244 244 { 1: x/i $pc 0xa90b4 : add %sp, -232, %sp (gdb) print /x $g6 $7 = 0x322e3100 (gdb) stepi 0x000a90b8 in cpu_x86_exec (env1=0x117000) at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:244 244 { 1: x/i $pc 0xa90b8 : st %i7, [ %sp + 0x60 ] (gdb) print /x $g6 $8 = 0x322e3100 (gdb) stepi 0x000a90bc 244 { 1: x/i $pc 0xa90bc : sub %sp, -232, %i7 (gdb) print /x $g6 $9 = 0x322e3100 (gdb) I still read that as failing to assign the value. Given my limited knowledge, how is gdb so adamantly stating that env1=0x117000 when the value of env1 (i.e. env in the calling function) is only known after the delay slot instruction is completed? That's more a rhetorical question... I've got to do a bit of research to be able to know these things myself. >> 0x240a4 : sethi %hi(0x258800), %g4 >> 0x240a8 : or %g4, 0x4c, %g4 ! 0x25884c >> 0x240ac : ld [ %g4 ], %g4 >> 0x240b0 : st %g4, [ %fp + -20 ] >> 0x240b4 : ld [ %fp + -20 ], %o0 >> 0x240b8 : call 0x14fa64 >> 0x240bc : nop > > This looks like equivalent code, only dumber version using an > intermediate store and not using the delay slot. Sure. However, what do you read of gdb determining that the value for env in the parameters to the cpu_exec call being different to its value in the calling function? Regards, Shaddy