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:30:00 -0000 [thread overview]
Message-ID: <47279E22.4040800@linux.vnet.ibm.com> (raw)
In-Reply-To: <200710302102.l9UL2kmf024428@d12av02.megacenter.de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
-----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-----
[-- Attachment #2: gcore-altivec.diff --]
[-- Type: text/x-patch, Size: 4467 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
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 --]
next prev parent reply other threads:[~2007-10-30 21:12 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
2007-10-30 21:18 ` Ulrich Weigand
2007-10-30 21:30 ` Carlos Eduardo Seo [this message]
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=47279E22.4040800@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