From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28286 invoked by alias); 23 Aug 2013 00:48:42 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 28276 invoked by uid 89); 23 Aug 2013 00:48:42 -0000 X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO autolearn=ham version=3.3.2 Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 23 Aug 2013 00:48:41 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id F2C87116821; Thu, 22 Aug 2013 20:48:44 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id W9w2M5MDWRHV; Thu, 22 Aug 2013 20:48:44 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9108511681C; Thu, 22 Aug 2013 20:48:44 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 401A2C3DA9; Thu, 22 Aug 2013 17:48:37 -0700 (PDT) Date: Fri, 23 Aug 2013 00:48:00 -0000 From: Joel Brobecker To: David Edelsohn Cc: Raunaq 12 , GDB Patches , Mark Kettenis , Ulrich Weigand Subject: [RFA/ppc-aix] fix thread support breakage (was: "Re: [PATCH 4/5] powerpc64-aix ptrace64 when defined.") Message-ID: <20130823004837.GC5221@adacore.com> References: <20130822233234.GA13292@adacore.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20130822233234.GA13292@adacore.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Found: No X-SW-Source: 2013-08/txt/msg00657.txt.bz2 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 844 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 --BXVAT5kNtrzKuDFl Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-thread-support-broken-on-ppc-aix.patch" Content-length: 2061 >From 91f7d8c9ae626954479217739aaa476e79e5daeb Mon Sep 17 00:00:00 2001 From: Joel Brobecker 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 --BXVAT5kNtrzKuDFl--