32bit code under 64bit gdb on Solaris9 reads memory incorrectly.

[Pawel S. Veselov]

Hi,

Since 6.5, I'm having problems with debugging 32bit programs under 64bit gdb on
Solaris 9. It gives a lot of "Cannot access memory at address" messages where
it's not supposed to. I've checked gdb 6.6 to see if it's any better, but it's
not. So I patched the target.c (all gdb 6.6 now):

---------------------------- CUT ----------------------------

[EMAIL PROTECTED]/sources/gdb-6.6/gdb$ gdiff -u target.c.orig target.c
--- target.c.orig       Tue May 15 17:23:54 2007
+++ target.c    Tue May 15 17:24:02 2007
@@ -1169,6 +1169,10 @@
 int
 target_read_memory (CORE_ADDR memaddr, gdb_byte *myaddr, int len)
 {
+
+    fprintf(stderr, "rmem: memaddr=%lx, my=%lx, len=%d\n",
+            memaddr, myaddr, len);
+    
   if (target_read (&current_target, TARGET_OBJECT_MEMORY, NULL,
                   myaddr, memaddr, len) == len)
     return 0;

---------------------------- CUT ----------------------------

and ran it against a simple program:

---------------------------- CUT ----------------------------
[EMAIL PROTECTED]/tmp$ uname -a
SunOS druid 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Blade-1000
[EMAIL PROTECTED]/tmp$ gcc -m32 -g -o 2 2.c
[EMAIL PROTECTED]/tmp$ gcc -v
Reading specs from /static/bin/../lib/gcc-lib/sparc-sun-solaris2.9/3.3/specs
Configured with: ../gcc-3.3/configure --sysconfdir=/etc --localstatedir=/var 
--prefix=/static/stow/gcc-3.3 --exec-prefix=/static/stow/gcc-3.3 
--enable-threads --enable-languages=c,c++,f77,objc
Thread model: posix
gcc version 3.3
[EMAIL PROTECTED]/tmp$ cat 2.c
#include <stdio.h>
#include <strings.h>
int main(int argc, char ** argv) {
    char * lcType = strdup("smi");
    return 0;
}
[EMAIL PROTECTED]/tmp$ 
---------------------------- CUT ----------------------------

And then started to debug the sample program with GDB:

---------------------------- CUT ----------------------------
[EMAIL PROTECTED]/sources/gdb-6.6/gdb$ ./gdb /tmp/2
GNU gdb 6.6
[ skipped ]
(gdb) break main
Breakpoint 1 at 0x10678: file 2.c, line 5.
(gdb) run
Starting program: /tmp/2 
rmem: memaddr=207fc, my=ffffffff7fffdbd0, len=184
rmem: memaddr=207fc, my=ffffffff7fffd8e0, len=184
rmem: memaddr=207fc, my=ffffffff7fffd8e0, len=184
rmem: memaddr=10678, my=100687ce0, len=4
rmem: memaddr=ff3cd718, my=1006ee660, len=4

[ skipped ]

Breakpoint 1, main (rmem: memaddr=1066c, my=ffffffff7fffd130, len=4
rmem: memaddr=ffbff7dc, my=100687170, len=4
argc=0x1, rmem: memaddr=ffbff7e0, my=100861470, len=4
argv=0xffbff7fc) at 2.c:5
5           char * lcType = strdup("smi");
(gdb) next
rmem: memaddr=10678, my=100687ce0, len=4
rmem: memaddr=ff3cd718, my=1006ee660, len=4
rmem: memaddr=10688, my=ffffffff7fffd4e0, len=4
rmem: memaddr=1066c, my=ffffffff7fffd310, len=4
rmem: memaddr=10688, my=100687140, len=4
rmem: memaddr=1066c, my=ffffffff7fffd1d0, len=4
rmem: memaddr=1066c, my=ffffffff7fffd3f0, len=4
6       }
(gdb) print lcType
rmem: memaddr=1ffbff784, my=1006c6bc0, len=4
Cannot access memory at address 0xffbff784
(gdb) quit
The program is running.  Exit anyway? (y or n) y
[EMAIL PROTECTED]/sources/gdb-6.6/gdb$ 
---------------------------- CUT ----------------------------

Note the 'memaddr' address has the 33rd bit set in the last memory access.

So when I added the 'memaddr &= 0xffffffff;' after the 'fpritnf' call in the
above patch, it started to work perfectly. So, something is incorrectly setting
that 33rd bit in the target memory's address. There are no problems debugging
64bit programs.

Any ideas why ? :)

(please cc: me directly in the replies, I'm not on this alias.)

Thanks !
    Pawel.



_______________________________________________
bug-gdb mailing list
bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb