🚀 go-pugleaf

Hi again,

I tried to trace how the address gets this value. The address is computed in
findvar.c:495
    addr = get_frame_local_address(frame);
    addr += SYMBOL_VALUE(var);

For me, get_frame_local_address() returned 0xffbff778 (seems ok), and the
value.ivalue (SYMBOL_VALUE) was 0xffffffec, so add them together, you get
0x1ffbff764, which is wrong. It seems that the problem is that ivalue is 32 bit
long, and is negative, and ivalue should've been a 64bit long negative, than
the addition would have spilled into the carry flag, instead of 33rd bit
(wouldn't frame address also need to be a full 64bit negative ? not sure...).

Not sure how to address this an easy way :)

Thanks,
    Pawel.

On Tue, May 15, 2007 at 05:59:27PM -0700, Pawel S. Veselov wrote:
>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.
>

Bye.
--
 Pawel S. Veselov [vps], Sun Microsystems, Inc.
 Senior Staff Engineer, Consumer and Mobile Systems group.    __ __(O) _ __
   (408) 276-5410   e-mail: Pawel.Veselov@Sun.COM             \ V /| || '  \
fax(408) 276-6090 HomePage: http://manticore.2y.net            \_/ |_||_|_|_|