This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[RFA/ppc-aix] fix thread support breakage (was: "Re: [PATCH 4/5] powerpc64-aix ptrace64 when defined.")
- From: Joel Brobecker <brobecker at adacore dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: Raunaq 12 <raunaq12 at in dot ibm dot com>, GDB Patches <gdb-patches at sourceware dot org>, Mark Kettenis <mark dot kettenis at xs4all dot nl>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- Date: Thu, 22 Aug 2013 17:48:37 -0700
- Subject: [RFA/ppc-aix] fix thread support breakage (was: "Re: [PATCH 4/5] powerpc64-aix ptrace64 when defined.")
- References: <CAGWvnynVeLt6F-QREsP_CtQvwvtZgwqHxtcS6pn58LMf=AX=GA at mail dot gmail dot com> <OF91B6D42F dot B0CFCB9C-ON65257BC5 dot 004284AA-65257BC5 dot 0042F553 at in dot ibm dot com> <CAGWvnynzsNL--qPhHOhqZ912A4M9ZpXtT2JbjW4EHRodEXAF9Q at mail dot gmail dot com> <20130822233234 dot GA13292 at adacore dot com>
Hello again,
> Actually, I just found that it breaks thread support on 32bit AIX,
> at least. A simpler way to show the problem is:
>
> (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
Attached is the patch I checked in locally at AdaCore:
gdb/ChangeLog:
* rs6000-nat.c (rs6000_ptrace32): Cast "addr" to "uintptr_t"
instead of "long long" in call to ptrace64.
Tested on ppc-aix in full 32bit mode (both GDB and inferior are
32bit). I think the other scenario would be 64bit GDB debugging
a 32bit inferior, but I don't have a 64bit compiler to try it.
I'd like to commit this patch, unless there are comments/suggestions.
Thank you,
--
Joel
>From 91f7d8c9ae626954479217739aaa476e79e5daeb Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
Date: Thu, 22 Aug 2013 20:33:27 -0400
Subject: [PATCH] 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.
---
gdb/rs6000-nat.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gdb/rs6000-nat.c b/gdb/rs6000-nat.c
index 0953356..b214cd9 100644
--- a/gdb/rs6000-nat.c
+++ b/gdb/rs6000-nat.c
@@ -132,7 +132,7 @@ static int
rs6000_ptrace32 (int req, int id, int *addr, int data, int *buf)
{
#ifdef HAVE_PTRACE64
- int ret = ptrace64 (req, id, (long long) addr, data, buf);
+ int ret = ptrace64 (req, id, (uintptr_t) addr, data, buf);
#else
int ret = ptrace (req, id, (int *)addr, data, buf);
#endif
--
1.7.0.4