On 12/6/07, Shaddy Baddah <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Blue Swirl wrote:
> > On 12/5/07, Shaddy Baddah <[EMAIL PROTECTED]> 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?
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 <cpu_sparc_exec+4>: st %i7, [ %sp + 0x60 ]
(gdb)
0x00074a28 244 {
2: /x $sp = 0xff7e2388
1: x/i $pc 0x74a28 <cpu_sparc_exec+8>: 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 <cpu_sparc_exec+12>: 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.
