Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: GDB Patches <gdb-patches@sourceware.org>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, "H.J. Lu" <hjl.tools@gmail.com>
Subject: i387-tdep.c:i387_supply_xsave: Assert the xsave section buffer, is not NULL.
Date: Mon, 05 Mar 2012 14:32:00 -0000	[thread overview]
Message-ID: <4F54CE80.30204@redhat.com> (raw)
In-Reply-To: <4F21A489.2080200@redhat.com>

On 01/26/2012 07:07 PM, Pedro Alves wrote:

> 
> I have a doubt in the xsave-in-corefile support bits.  There's code in place to
> handle a NULL regs (as in no xsave contents to work with), so I'm handling it
> as presently:
> 
> +
> +     Note however, the case when REGS is NULL is a different case.
> +     That case means we do not have access to the x87 states, so we
> +     should mark the registers as unavailable (by supplying NULL).  */
> +
> 
> but I can't figure out how would we ever get a NULL REGS there.  Is there a
> convoluted path I missed?  amd64-linux-tdep.c unconditionally installs
> amd64_linux_regset_sections as gdbarch_core_regset_sections
> callback, and this includes the .reg-xstate section.
> However, corelow.c:get_core_register_section bails early if
> a section is not found in the core, never reaching regset->supply_regset
> with a NULL `contents'.


On 02/27/2012 06:48 PM, Pedro Alves wrote:
> I'll post a separate RFC patch proposing to remove the NULL REGS handling

Here's what I'd like to check in, given the analysis quoted above.

2012-03-05  Pedro Alves  <palves@redhat.com>

	* i387-tdep.c (i387_supply_xsave): Assert the xsave section buffer
	is not NULL, and remove resulting dead code.

---

 gdb/i387-tdep.c |   33 +++++++++++----------------------
 1 files changed, 11 insertions(+), 22 deletions(-)

diff --git a/gdb/i387-tdep.c b/gdb/i387-tdep.c
index 3fc344d..26e4e50 100644
--- a/gdb/i387-tdep.c
+++ b/gdb/i387-tdep.c
@@ -790,6 +790,7 @@ i387_supply_xsave (struct regcache *regcache, int regnum,
       all = x87 | sse | avxh
     } regclass;

+  gdb_assert (regs != NULL);
   gdb_assert (tdep->st0_regnum >= I386_ST0_REGNUM);
   gdb_assert (tdep->num_xmm_regs > 0);

@@ -807,7 +808,7 @@ i387_supply_xsave (struct regcache *regcache, int regnum,
   else
     regclass = none;

-  if (regs != NULL && regclass != none)
+  if (regclass != none)
     {
       /* Get `xstat_bv'.  */
       const gdb_byte *xstate_bv_p = XSAVE_XSTATE_BV_ADDR (regs);
@@ -826,11 +827,7 @@ i387_supply_xsave (struct regcache *regcache, int regnum,
      time in a program.  This means that from the user-space programs'
      perspective, it's the same as if the registers have always been
      zero from the start of the program.  Therefore, the debugger
-     should provide the same illusion to the user.
-
-     Note however, the case when REGS is NULL is a different case.
-     That case means we do not have access to the x87 states, so we
-     should mark the registers as unavailable (by supplying NULL).  */
+     should provide the same illusion to the user.  */

   switch (regclass)
     {
@@ -839,7 +836,7 @@ i387_supply_xsave (struct regcache *regcache, int regnum,

     case avxh:
       if ((clear_bv & I386_XSTATE_AVX))
-	regcache_raw_supply (regcache, regnum, regs == NULL ? NULL : zero);
+	regcache_raw_supply (regcache, regnum, zero);
       else
 	regcache_raw_supply (regcache, regnum,
 			     XSAVE_AVXH_ADDR (tdep, regs, regnum));
@@ -847,7 +844,7 @@ i387_supply_xsave (struct regcache *regcache, int regnum,

     case sse:
       if ((clear_bv & I386_XSTATE_SSE))
-	regcache_raw_supply (regcache, regnum, regs == NULL ? NULL : zero);
+	regcache_raw_supply (regcache, regnum, zero);
       else
 	regcache_raw_supply (regcache, regnum,
 			     FXSAVE_ADDR (tdep, regs, regnum));
@@ -855,7 +852,7 @@ i387_supply_xsave (struct regcache *regcache, int regnum,

     case x87:
       if ((clear_bv & I386_XSTATE_X87))
-	regcache_raw_supply (regcache, regnum, regs == NULL ? NULL : zero);
+	regcache_raw_supply (regcache, regnum, zero);
       else
 	regcache_raw_supply (regcache, regnum,
 			     FXSAVE_ADDR (tdep, regs, regnum));
@@ -870,7 +867,7 @@ i387_supply_xsave (struct regcache *regcache, int regnum,
 	      for (i = I387_YMM0H_REGNUM (tdep);
 		   i < I387_YMMENDH_REGNUM (tdep);
 		   i++)
-		regcache_raw_supply (regcache, i, regs == NULL ? NULL : zero);
+		regcache_raw_supply (regcache, i, zero);
 	    }
 	  else
 	    {
@@ -890,7 +887,7 @@ i387_supply_xsave (struct regcache *regcache, int regnum,
 	      for (i = I387_XMM0_REGNUM (tdep);
 		   i < I387_MXCSR_REGNUM (tdep);
 		   i++)
-		regcache_raw_supply (regcache, i, regs == NULL ? NULL : zero);
+		regcache_raw_supply (regcache, i, zero);
 	    }
 	  else
 	    {
@@ -909,7 +906,7 @@ i387_supply_xsave (struct regcache *regcache, int regnum,
 	      for (i = I387_ST0_REGNUM (tdep);
 		   i < I387_FCTRL_REGNUM (tdep);
 		   i++)
-		regcache_raw_supply (regcache, i, regs == NULL ? NULL : zero);
+		regcache_raw_supply (regcache, i, zero);
 	    }
 	  else
 	    {
@@ -926,12 +923,6 @@ i387_supply_xsave (struct regcache *regcache, int regnum,
   for (i = I387_FCTRL_REGNUM (tdep); i < I387_XMM0_REGNUM (tdep); i++)
     if (regnum == -1 || regnum == i)
       {
-	if (regs == NULL)
-	  {
-	    regcache_raw_supply (regcache, i, NULL);
-	    continue;
-	  }
-
 	/* Most of the FPU control registers occupy only 16 bits in
 	   the xsave extended state.  Give those a special treatment.  */
 	if (i != I387_FIOFF_REGNUM (tdep)
@@ -982,10 +973,8 @@ i387_supply_xsave (struct regcache *regcache, int regnum,
       }

   if (regnum == I387_MXCSR_REGNUM (tdep) || regnum == -1)
-    {
-      p = regs == NULL ? NULL : FXSAVE_MXCSR_ADDR (regs);
-      regcache_raw_supply (regcache, I387_MXCSR_REGNUM (tdep), p);
-    }
+    regcache_raw_supply (regcache, I387_MXCSR_REGNUM (tdep),
+			 FXSAVE_MXCSR_ADDR (regs));
 }

 /* Similar to i387_collect_fxsave, but use XSAVE extended state.  */


  parent reply	other threads:[~2012-03-05 14:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-26 19:16 AVX and unavailable registers, fix system-gcore.exp Pedro Alves
2012-02-27 18:49 ` H.J. Lu
2012-02-27 19:23   ` Pedro Alves
2012-03-02 21:49     ` H.J. Lu
2012-03-05 14:24       ` Pedro Alves
2012-03-06 13:22         ` Pedro Alves
2012-03-05 14:32 ` Pedro Alves [this message]
2012-03-05 15:51   ` i387-tdep.c:i387_supply_xsave: Assert the xsave section buffer, is not NULL Mark Kettenis
2012-03-05 16:19     ` Pedro Alves

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=4F54CE80.30204@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=mark.kettenis@xs4all.nl \
    /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