Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: GDB Patches Mailing List <gdb-patches@sourceware.org>
Subject: Re: [RFC] Add support for PPC Altivec registers in gcore
Date: Tue, 30 Oct 2007 21:02:00 -0000	[thread overview]
Message-ID: <472798F0.8050303@linux.vnet.ibm.com> (raw)
In-Reply-To: <200710291916.l9TJGjHh028749@d12av02.megacenter.de.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the comments Ulrich.

So, does this one look like a good start?

About the new gdbarch variable, do you think it's a good idea to
introduce it now, only with .reg-ppc-vmx and .reg-xfp on the list, or
you'd rather do a full rework later in GDB in order to remove all
fill_ fallbacks make linux-nat/corelow code get everything from there?

Regards,

- --
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

iD8DBQFHJ5jvqvq7Aov/qQARAg2BAJ9i261fLd9mkPcRhrA5gQW2CdN7BQCeJm7+
y1ku/vUr6wYBdlzfCXCZEXM=
=vhiU
-----END PGP SIGNATURE-----


[-- Attachment #2: gcore-altivec.diff --]
[-- Type: text/x-patch, Size: 4639 bytes --]

2007-10-30  Carlos Eduardo Seo  <cseo@linux.vnet.ibm.com>

	* 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
@@ -687,7 +655,7 @@ store_register (const struct regcache *r
     }
 }
 
-static void
+void
 fill_vrregset (const struct regcache *regcache, gdb_vrregset_t *vrregsetp)
 {
   int i;
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

[-- Attachment #3: gcore-altivec.diff.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

  reply	other threads:[~2007-10-30 20:50 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-26 22:14 Carlos Eduardo Seo
2007-10-29 19:24 ` Ulrich Weigand
2007-10-30 21:02   ` Carlos Eduardo Seo [this message]
2007-10-30 21:18     ` Ulrich Weigand
2007-10-30 21:30       ` Carlos Eduardo Seo
2007-10-30 21:31         ` Ulrich Weigand
2007-10-31 21:14           ` Carlos Eduardo Seo
2007-10-31 21:43             ` Ulrich Weigand
2008-02-08 21:42               ` Carlos Eduardo Seo
2008-02-18 18:42                 ` Ulrich Weigand
2008-02-27 17:07                   ` Carlos Eduardo Seo
2008-03-05 18:27                     ` Ulrich Weigand
2008-03-10 14:22                   ` Carlos Eduardo Seo
2008-03-17 19:07                     ` Ulrich Weigand
2008-03-20 15:31                       ` Carlos Eduardo Seo
2008-03-25 20:13                         ` Ulrich Weigand
2008-03-25 21:31                           ` Andreas Schwab
2008-03-25 21:54                             ` Ulrich Weigand
2008-03-25 22:46                               ` Carlos Eduardo Seo
2008-03-26 11:28                                 ` Ulrich Weigand
2008-03-27  1:52                       ` Carlos Eduardo Seo
2008-03-27  9:00                         ` Andreas Schwab
2008-03-27 19:54                         ` Ulrich Weigand
2008-03-28 20:41                           ` Carlos Eduardo Seo
2008-03-31 19:19                             ` Ulrich Weigand
2008-05-09 19:27                               ` Carlos Eduardo Seo
2008-05-09 20:30                                 ` Ulrich Weigand
2008-05-10  1:33                                   ` Carlos Eduardo Seo
2008-05-14  4:22                                     ` Ulrich Weigand
2008-05-20 18:41                                       ` Carlos Eduardo Seo
2008-05-21 18:46                                         ` Ulrich Weigand
2008-05-22 14:34                                           ` Carlos Eduardo Seo
2008-05-22 18:45                                             ` Ulrich Weigand
2008-05-26 16:26                                               ` Carlos Eduardo Seo
     [not found] <OF67129E0D.852FADB2-ON4125738B.0050E74D-4125738B.005102FF@de.ibm.com>
2007-11-25  4:51 ` Carlos Eduardo Seo
2007-11-26 16:09   ` Ulrich Weigand
2007-11-26 16:12     ` Carlos Eduardo Seo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=472798F0.8050303@linux.vnet.ibm.com \
    --to=cseo@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox