🚀 go-pugleaf

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 ----------------------------

[pv76716@druid]~/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 ----------------------------
[pv76716@druid]/tmp$ uname -a
SunOS druid 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Blade-1000
[pv76716@druid]/tmp$ gcc -m32 -g -o 2 2.c
[pv76716@druid]/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
[pv76716@druid]/tmp$ cat 2.c
#include <stdio.h>
#include <strings.h>
int main(int argc, char ** argv) {
    char * lcType = strdup("smi");
    return 0;
}
[pv76716@druid]/tmp$ 
---------------------------- CUT ----------------------------

And then started to debug the sample program with GDB:

---------------------------- CUT ----------------------------
[pv76716@druid]~/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
[pv76716@druid]~/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.