This is the mail archive of the
gdb-cvs@sourceware.org
mailing list for the GDB project.
src/gdb ChangeLog rs6000-nat.c
- From: brobecke at sourceware dot org
- To: gdb-cvs at sourceware dot org
- Date: Thu, 29 Aug 2013 21:02:15 +0000
- Subject: src/gdb ChangeLog rs6000-nat.c
CVSROOT: /cvs/src
Module name: src
Changes by: brobecke@sourceware.org 2013-08-29 21:02:15
Modified files:
gdb : ChangeLog rs6000-nat.c
Log message:
thread support broken on ppc-aix.
Thread support got broken when adding 64bit support on ppc-aix.
Upon digging further, I found that the following patch...
| * gdb_ptrace.h: Use ptrace64 instead of ptrace if HAVE_PTRACE64
| is defined.
| * rs6000-nat.c: Check for __ld_info64_ if compiling 64 BIT gdb.
| (rs6000_ptrace32): Call ptrace64 instead of ptrace if present.
| (rs6000_ptrace64): Call ptace64 instead of ptracex if present.
| * configure.ac: Check for ptrace64.
| * configure, config.in: Regenerate.
... is responsible for this regression:
(gdb) x /x &__n_pthreads
0xf06a8258 <__n_pthreads>: Cannot access memory at address 0xf06a8258
Prior to the patch, we have:
(gdb) x /x &__n_pthreads
0xf06a8258 <__n_pthreads>: 0x00000003
The problem occurs inside rs6000_ptrace32, while calling ptrace64.
The address is given to rs6000_ptrace32 as an "int *", while
ptrace64 takes a "long long". The cast causes the address to be
sign-extended, which results in GDB trying to read the wrong address.
This patch fixes the issue by casting the address to a "uintptr_t"
instead, and letting the compiler do the implicit conversion to
"long long" in the function call.
gdb/ChangeLog:
* rs6000-nat.c (rs6000_ptrace32): Cast "addr" to "uintptr_t"
instead of "long long" in call to ptrace64.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.15950&r2=1.15951
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/rs6000-nat.c.diff?cvsroot=src&r1=1.130&r2=1.131