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

[Shaddy Baddah <shaddy.baddah@shaddybaddah.name>]

Hi,

Blue Swirl wrote:
> On 12/5/07, Shaddy Baddah <shaddy.baddah@shaddybaddah.name> 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