From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8750 invoked by alias); 30 Oct 2007 21:12:12 -0000 Received: (qmail 8735 invoked by uid 22791); 30 Oct 2007 21:12:08 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 30 Oct 2007 21:12:05 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id 590CF17F4B0 for ; Tue, 30 Oct 2007 19:09:11 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9ULC1F91912910 for ; Tue, 30 Oct 2007 19:12:01 -0200 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9ULC1NI005281 for ; Tue, 30 Oct 2007 18:12:01 -0300 Received: from [9.18.238.59] (dyn531792.br.ibm.com [9.18.238.59]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9ULC1BY005261; Tue, 30 Oct 2007 18:12:01 -0300 Message-ID: <47279E22.4040800@linux.vnet.ibm.com> Date: Tue, 30 Oct 2007 21:30:00 -0000 From: Carlos Eduardo Seo User-Agent: Thunderbird 2.0.0.6 (X11/20070907) MIME-Version: 1.0 To: Ulrich Weigand CC: GDB Patches Mailing List Subject: Re: [RFC] Add support for PPC Altivec registers in gcore References: <200710302102.l9UL2kmf024428@d12av02.megacenter.de.ibm.com> In-Reply-To: <200710302102.l9UL2kmf024428@d12av02.megacenter.de.ibm.com> OpenPGP: id=8BFFA900 Content-Type: multipart/mixed; boundary="------------040006020309080108010609" X-IsSubscribed: yes 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 X-SW-Source: 2007-10/txt/msg00831.txt.bz2 This is a multi-part message in MIME format. --------------040006020309080108010609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 1061 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ulrich Weigand wrote: > > Completely removing all the fallbacks seems quite a bit of work; > if you want to work on it that would certainly be welcome. > > However, I think it would be OK to start with having the gdbarch > variable only contain the *extra* register sets, beyond the core > and floating-point sets. > Ok. So, this would require removing the FILL_FPXREGSET ifdefs and all the fill_fpxregset fallbacks. I think this is OK, but won't it break anything in x86? > > If we do not have a collect_regset, we certainly do not want to > write an note section containing uninitialized data. The > elfcore_write_ppc_vmx call needs to be inside the "if" block ... Corrected. Thanks, - -- Carlos Eduardo Seo Software Engineer IBM Linux Technology Center -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJ54hqvq7Aov/qQARArXXAJ4z8a5f0YMzM2QxKX2QkuiJLTcGhgCbBsnS NrH8jrngJzujytVbM/7wlXI= =kR1E -----END PGP SIGNATURE----- --------------040006020309080108010609 Content-Type: text/x-patch; name="gcore-altivec.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcore-altivec.diff" Content-length: 4467 2007-10-30 Carlos Eduardo Seo * linux-nat.c (linux_nat_do_thread_registers): Added support for PPC Altivec registers. * ppc-linux-nat.c: Removed definitions of SIZEOF_VRREGS and gdb_vrregset_t. * gregset.h: Added definitions of SIZEOF_VRREGS and gdb_vrregset_t. Index: src/gdb/linux-nat.c =================================================================== --- src.orig/gdb/linux-nat.c +++ src/gdb/linux-nat.c @@ -2616,6 +2616,7 @@ linux_nat_do_thread_registers (bfd *obfd { gdb_gregset_t gregs; gdb_fpregset_t fpregs; + gdb_vrregset_t vrregs; #ifdef FILL_FPXREGSET gdb_fpxregset_t fpxregs; #endif @@ -2676,6 +2677,19 @@ linux_nat_do_thread_registers (bfd *obfd note_size, &fpxregs, sizeof (fpxregs)); #endif + + if (core_regset_p + && (regset = gdbarch_regset_from_core_section (gdbarch, ".reg-ppc-vmx", + sizeof (vrregs))) != NULL + && regset->collect_regset != NULL) + { + regset->collect_regset (regset, regcache, -1, + &vrregs, sizeof (vrregs)); + note_data = (char *) elfcore_write_ppc_vmx (obfd, + note_data, + note_size, + &vrregs, sizeof (vrregs)); + } return note_data; } Index: src/gdb/ppc-linux-nat.c =================================================================== --- src.orig/gdb/ppc-linux-nat.c +++ src/gdb/ppc-linux-nat.c @@ -79,38 +79,6 @@ #define PTRACE_GETSIGINFO 0x4202 #endif -/* This oddity is because the Linux kernel defines elf_vrregset_t as - an array of 33 16 bytes long elements. I.e. it leaves out vrsave. - However the PTRACE_GETVRREGS and PTRACE_SETVRREGS requests return - the vrsave as an extra 4 bytes at the end. I opted for creating a - flat array of chars, so that it is easier to manipulate for gdb. - - There are 32 vector registers 16 bytes longs, plus a VSCR register - which is only 4 bytes long, but is fetched as a 16 bytes - quantity. Up to here we have the elf_vrregset_t structure. - Appended to this there is space for the VRSAVE register: 4 bytes. - Even though this vrsave register is not included in the regset - typedef, it is handled by the ptrace requests. - - Note that GNU/Linux doesn't support little endian PPC hardware, - therefore the offset at which the real value of the VSCR register - is located will be always 12 bytes. - - The layout is like this (where x is the actual value of the vscr reg): */ - -/* *INDENT-OFF* */ -/* - |.|.|.|.|.....|.|.|.|.||.|.|.|x||.| - <-------> <-------><-------><-> - VR0 VR31 VSCR VRSAVE -*/ -/* *INDENT-ON* */ - -#define SIZEOF_VRREGS 33*16+4 - -typedef char gdb_vrregset_t[SIZEOF_VRREGS]; - - /* On PPC processors that support the the Signal Processing Extension (SPE) APU, the general-purpose registers are 64 bits long. However, the ordinary Linux kernel PTRACE_PEEKUSER / PTRACE_POKEUSER Index: src/gdb/gregset.h =================================================================== --- src.orig/gdb/gregset.h +++ src/gdb/gregset.h @@ -72,4 +72,37 @@ extern void fill_fpxregset (const struct gdb_fpxregset_t *fpxregs, int regno); #endif +/* For PPC Altivec support */ + +/* This oddity is because the Linux kernel defines elf_vrregset_t as + an array of 33 16 bytes long elements. I.e. it leaves out vrsave. + However the PTRACE_GETVRREGS and PTRACE_SETVRREGS requests return + the vrsave as an extra 4 bytes at the end. I opted for creating a + flat array of chars, so that it is easier to manipulate for gdb. + + There are 32 vector registers 16 bytes longs, plus a VSCR register + which is only 4 bytes long, but is fetched as a 16 bytes + quantity. Up to here we have the elf_vrregset_t structure. + Appended to this there is space for the VRSAVE register: 4 bytes. + Even though this vrsave register is not included in the regset + typedef, it is handled by the ptrace requests. + + Note that GNU/Linux doesn't support little endian PPC hardware, + therefore the offset at which the real value of the VSCR register + is located will be always 12 bytes. + + The layout is like this (where x is the actual value of the vscr reg): */ + +/* *INDENT-OFF* */ +/* + |.|.|.|.|.....|.|.|.|.||.|.|.|x||.| + <-------> <-------><-------><-> + VR0 VR31 VSCR VRSAVE +*/ +/* *INDENT-ON* */ + +#define SIZEOF_VRREGS 33*16+4 + +typedef char gdb_vrregset_t[SIZEOF_VRREGS]; + #endif --------------040006020309080108010609 Content-Type: application/octet-stream; name="gcore-altivec.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gcore-altivec.diff.sig" Content-length: 90 iD8DBQBHJ54hqvq7Aov/qQARAoUZAJ4vkkFVMGoF2CZF5x+Vb2hggeKRYwCf ZLaf0Itj03qv9SLRXjjkAque8ds= --------------040006020309080108010609--