From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7874 invoked by alias); 10 Aug 2005 21:44:28 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7866 invoked by uid 22791); 10 Aug 2005 21:44:24 -0000 Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.130) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 10 Aug 2005 21:44:24 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7ALiMkQ758238 for ; Wed, 10 Aug 2005 17:44:22 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7ALi8fN538498 for ; Wed, 10 Aug 2005 15:44:08 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7ALiL4t016480 for ; Wed, 10 Aug 2005 15:44:21 -0600 Received: from dyn9047022128.beaverton.ibm.com (dyn9047022128.beaverton.ibm.com [9.47.22.128]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7ALiLhV016464 for ; Wed, 10 Aug 2005 15:44:21 -0600 From: Paul Gilliam Reply-To: pgilliam@us.ibm.com To: gdb@sources.redhat.com Subject: accessing altivec registers on ppc64 Date: Wed, 10 Aug 2005 21:44:00 -0000 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200508101512.38042.pgilliam@us.ibm.com> X-SW-Source: 2005-08/txt/msg00050.txt.bz2 On a GNU/linux system with kernel version 2.6.5-7.97-pmac64, I can't access the value in an altivec register. This is using close to the latest CVS head version of GDB as a native debugger on an apple G5 running SuSE SLES 9. In digging through the sources, I found the following in the function fetch_ppc_registers at line 487 of ppc-linux-nat.c: if (have_ptrace_getvrregs) if (tdep->ppc_vr0_regnum != -1 && tdep->ppc_vrsave_regnum != -1) fetch_altivec_registers (tid); have_ptrace_getvrregs is initialized to 1 and set to 0 only if a ptrace using PTRACE_GETVRREGS fails. tdep->ppc_vr0_regnum and ppc_vrsave_regnum are set in rs6000_gdbarch_init(), in a switch statement at line 3217 of file rs6000-tdep.c, depending on the value of v->mach. I my case, that value is 64 == bfd_mach_ppc64 so they are set to -1 and altivec registers are not fetched. But if I seperate out that case and make it assign values as the bfd_mach_ppc case does, fetch_altivec_registers is still not called. Does anyone know what's going on? On a related topic: When I do 'info vector', I get the first 31 general-purpose registers (r0 thru r30, but no r31) followed by the vector registers. Any idea why the first 31 GP regs are inlcuded? -=# Paul Gilliam #=-