qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] and now bus error for i386 guest


From: Shaddy Baddah
Subject: Re: [Qemu-devel] and now bus error for i386 guest
Date: Thu, 06 Dec 2007 11:17:29 +1100
User-agent: Thunderbird 1.5.0.14pre (X11/20071023)

Hi,

Blue Swirl wrote:
On 12/5/07, Shaddy Baddah <address@hidden> wrote:
0x1e958 <main+13992>:   ld  [ %l6 + 0x8c ], %l1
0x1e95c <main+13996>:   call  0xa90b4 <cpu_x86_exec>
0x1e960 <main+14000>:   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 <http://gnu.org/licenses/gpl.html>
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 <main+13992>:   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 <main+13996>:   call  0xa90b4 <cpu_x86_exec>
0x1e960 <main+14000>:   mov  %l1, %o0
(gdb)
0x0001e960      7366                    ret = cpu_exec(env);
1: x/i $pc
0x1e960 <main+14000>:   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 <cpu_x86_exec>: 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 <cpu_x86_exec+4>:       st  %i7, [ %sp + 0x60 ]
(gdb) print /x $g6
$8 = 0x322e3100
(gdb) stepi
0x000a90bc      244     {
1: x/i $pc
0xa90bc <cpu_x86_exec+8>:       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 <main_loop+152>:        sethi  %hi(0x258800), %g4
0x240a8 <main_loop+156>:        or  %g4, 0x4c, %g4      ! 0x25884c
0x240ac <main_loop+160>:        ld  [ %g4 ], %g4
0x240b0 <main_loop+164>:        st  %g4, [ %fp + -20 ]
0x240b4 <main_loop+168>:        ld  [ %fp + -20 ], %o0
0x240b8 <main_loop+172>:        call  0x14fa64 <cpu_x86_exec>
0x240bc <main_loop+176>:        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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]