This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Strange behavior of print command


Hello,

I've got a strange behavior when calling print command in the gdb
console for remote debugging. I've tried GDB version 6.4, 6.8. The
result is the same. Below is the log and my comment. My comment is
started with <====.

GNU gdb 6.8
Copyright (C) 2008 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 "--host=i686-pc-linux-gnu --target=mips-elf".
(gdb) target remote :12107
Remote debugging using :12107
0xbfc00000 in ?? ()
(gdb) set debug remote 1
(gdb) p /x $sp
$1 = 0xffffffff
<==== Original value of register sp.

(gdb) p /x $sp=0x11223344
Sending packet: $P1d=11223344#b6...Ack
Packet received: OK
Packet P (set-register) is supported
Sending packet: $g#67...Ack
Packet received:
00000000fffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffff0040000000000000000000000000000000000000bfc0000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000
Sending packet: $mbfc00000,4#e8...Ack
Packet received: 1fc00000
$2 = 0x11223344
<==== I try to set sp to a new value of 0x11223344. However, the action
fails, we can see from the "g" packet response that the value of sp is
still 0xffffffff. However, the temporary variable of GDB "$2" printed as
the new value. That's strange, since the value of sp is still
0xffffffff. We can see that the behavior to print a memory local seems
more reasonable below.

(gdb) p /x *0xbfc00000
Sending packet: $mbfc00000,4#e8...Ack
Packet received: 1fc00000
$3 = 0x1fc00000
<==== Original value at 0xbfc00000.

(gdb) p /x *0xbfc00000=0x11223344
Sending packet: $Xffffffffbfc00000,0:#39...Ack
Packet received: OK
binary downloading suppported by target
Sending packet: $Xbfc00000,4:\021"3D#b7...Ack
Packet received: OK
Sending packet: $mbfc00000,4#e8...Ack
Packet received: 1fc00000
Sending packet: $mbfc00000,4#e8...Ack
Packet received: 1fc00000
$4 = 0x1fc00000
<==== Try to set memory at 0xbfc00000 to 0x11223344. However, the action
fails, and we can see the "m" command has a reponse of the original
value of 0x1fc00000. The temporary variable of GDB "$4" gives the right
value.

Why is the behavior for register and for memory different? The behavior
for register access seems wrong.

To reproduce the problem, just modify the gdb server in gdb relesae a
bit. Change the behavior to setting a regiter, just do nothing (not to
set the new value).

Best regards
Robert.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]