From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J0Ckj-0008EN-BB for qemu-devel@nongnu.org; Thu, 06 Dec 2007 04:10:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J0Cki-0008E2-HZ for qemu-devel@nongnu.org; Thu, 06 Dec 2007 04:10:40 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0Ckh-0008Dz-TB for qemu-devel@nongnu.org; Thu, 06 Dec 2007 04:10:39 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J0Ckh-0008Mr-AU for qemu-devel@nongnu.org; Thu, 06 Dec 2007 04:10:39 -0500 Received: by nf-out-0910.google.com with SMTP id 30so50848nfu for ; Thu, 06 Dec 2007 01:10:38 -0800 (PST) Message-ID: Date: Thu, 6 Dec 2007 11:10:37 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] and now bus error for i386 guest In-Reply-To: <47573F99.4060001@shaddybaddah.name> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <473A9DED.6020308@shaddybaddah.name> <473AAD7F.30709@shaddybaddah.name> <473AF480.6030802@shaddybaddah.name> <475554E1.5070509@shaddybaddah.name> <4756B6C9.3080507@shaddybaddah.name> <47573F99.4060001@shaddybaddah.name> 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 On 12/6/07, Shaddy Baddah wrote: > 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? Maybe the other function uses env which is the global register version and the other env from paramenters or gdb could be confused. (gdb) b *0x00074a20 Breakpoint 1 at 0x74a20: file /var/tmp/src/qemu.sparc/cpu-exec.c, line 244. (gdb) c [Switching to Thread 16384 (LWP 7110)] Breakpoint 1, cpu_sparc_exec (env1=0xa9c00) at /var/tmp/src/qemu.sparc/cpu-exec.c:244 244 { (gdb) display/i $pc (gdb) display/x $sp (gdb) stepi 0x00074a24 in cpu_sparc_exec (env1=0xa9c00) at /var/tmp/src/qemu.sparc/cpu-exec.c:244 244 { 2: /x $sp = 0xff7e2388 1: x/i $pc 0x74a24 : st %i7, [ %sp + 0x60 ] (gdb) 0x00074a28 244 { 2: /x $sp = 0xff7e2388 1: x/i $pc 0x74a28 : sub %sp, -200, %i7 (gdb) 0x00074a2c in cpu_sparc_exec (env1=0xa9c00) at /var/tmp/src/qemu.sparc/cpu-exec.c:244 244 { 2: /x $sp = 0xff7e2388 1: x/i $pc 0x74a2c : st %o7, [ %sp + 0x64 ] (gdb) Aborted Now /proc/7110/maps shows that 0xff7e2388 + 0x64 = 0xff7e23ec is a valid address: ff7bc000-ff7e6000 rw-p ff7bc000 00:00 0 [stack] Also the address is properly aligned, so the store should not fail. The stack address is a bit odd, I think it should be located below kernel.