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 0xffec, 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
>
>[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.cTue 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 (¤t_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
>#include
>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=7fffdbd0, len=184
>rmem: memaddr=207fc, my=7fffd8e0, len=184
>rmem: memaddr=207fc, my=7fffd8e0, len=184
>rmem: memaddr=10678, my=100687ce0, len=4
>rmem: memaddr=ff3cd718, my=1006ee660, len=4
>
>[ skipped ]
>
>Breakpoint 1, main (rmem: memaddr=1066c, my=7fffd130, 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=7fffd4e0, len=4
>rmem: memaddr=1066c, my=7fffd310, len=4
>rmem: memaddr=10688, my=100687140, len=4
>rmem: memaddr=1066c, my=7fffd1d0, len=4
>rmem: memaddr=1066c, my=7fffd3f0, 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 &= 0x;' 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: [EMAIL PROTECTED] \ V /| || ' \
fax(408) 276-6090 HomePage: http://manticore.2y.net\_/ |_||_|_|_|
___
bug-gdb mailing list
bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
