Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <andrew.burgess@embecosm.com>
Subject: [PATCH] gdb/x86: Fix write out of mxcsr register for xsave targets
Date: Fri, 11 May 2018 14:47:00 -0000	[thread overview]
Message-ID: <20180511115228.22098-1-andrew.burgess@embecosm.com> (raw)

In commit:

  commit 8ee22052f690c007556b97eed59f49350ece5ca9
  Author: Andrew Burgess <andrew.burgess@embecosm.com>
  Date:   Thu May 3 17:46:14 2018 +0100

      gdb/x86: Handle kernels using compact xsave format

in two places FXSAVE_ADDR was used instead of FXSAVE_MXCSR_ADDR to get
the address of the mxcsr register within the xsave buffer.  This will
mean we are potentially accessing the wrong location within the xsave
buffer.

There are no tests included with this patch.  The first mistake would
only trigger an issue if/when the user tries to manually set the mxcsr
register to a value that matches the random (value off stack) value
that is in the xsave buffer, in this case the change by the user will
go unnoticed by GDB, and the default value of mxcsr will be preserved.

The second mistake only happens on the code path where all x87
registers are being written out of the register cache.  I'm not sure
how to trigger that code path.

gdb/ChangeLog:

	* i387-tdep.c (i387_collect_xsave): Use FXSAVE_MXCSR_ADDR not
	FXSAVE_ADDR for the mxcsr register.
---
 gdb/ChangeLog   | 5 +++++
 gdb/i387-tdep.c | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/gdb/i387-tdep.c b/gdb/i387-tdep.c
index aca70c186f9..3effc35b174 100644
--- a/gdb/i387-tdep.c
+++ b/gdb/i387-tdep.c
@@ -1490,7 +1490,7 @@ i387_collect_xsave (const struct regcache *regcache, int regnum,
 	 require clearing.  */
       if ((clear_bv & (X86_XSTATE_AVX | X86_XSTATE_SSE))
 	  == (X86_XSTATE_AVX | X86_XSTATE_SSE))
-	store_unsigned_integer (FXSAVE_ADDR (tdep, regs, i), 2, byte_order,
+	store_unsigned_integer (FXSAVE_MXCSR_ADDR (regs), 2, byte_order,
 				I387_MXCSR_INIT_VAL);
 
       if ((clear_bv & X86_XSTATE_X87))
@@ -1643,7 +1643,7 @@ i387_collect_xsave (const struct regcache *regcache, int regnum,
 	{
 	  i = I387_MXCSR_REGNUM (tdep);
 	  regcache_raw_collect (regcache, i, raw);
-	  p = FXSAVE_ADDR (tdep, regs, i);
+	  p = FXSAVE_MXCSR_ADDR (regs);
 	  if (memcmp (raw, p, 4))
 	    {
 	      /* Now, we need to mark one of either SSE of AVX as enabled.
-- 
2.14.3


             reply	other threads:[~2018-05-11 11:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 14:47 Andrew Burgess [this message]
2018-05-11 18:26 ` Pedro Alves
2018-05-11 21:55   ` Andrew Burgess

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=20180511115228.22098-1-andrew.burgess@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    /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