This is the mail archive of the gdb-cvs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[binutils-gdb] S390: Fix for inadvertently setting 24-bit mode in fill_gregset


https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2492f0d005f0390eabb3deb58aa7db7fcd716763

commit 2492f0d005f0390eabb3deb58aa7db7fcd716763
Author: Andreas Arnez <arnez@linux.vnet.ibm.com>
Date:   Fri May 8 12:50:47 2015 +0200

    S390: Fix for inadvertently setting 24-bit mode in fill_gregset
    
    On 64-bit S390 platforms, for programs compiled with -m31, it could
    happen that GDB inadvertently cleared the inferior's 31-bit addressing
    mode bit and left the inferior running in 24-bit addressing mode.  In
    particular this occurred with checkpoint.exp, when the "restore"
    command needed to create a new regcache copy: At the time when the
    PSWM register was copied over, the addressing mode bit was taken from
    the PSWA register, which was still zero since it had not been copied
    yet.  And when the PSWA register was copied, the addressing mode was
    not updated again.
    
    The fix affects fill_gregset, where the bits "belonging" to each of
    the PSWA and PSWM registers are now carefully separated.  The
    addressing mode bit is no longer touched when writing PSWM, and --
    more importantly -- it *is* written when writing PSWA.
    
    gdb/ChangeLog:
    
    	* s390-linux-nat.c (fill_gregset): Avoid relying on the PSWA
    	register in the regcache when treating the PSWM register, and vice
    	versa.

Diff:
---
 gdb/ChangeLog        |  6 ++++++
 gdb/s390-linux-nat.c | 28 +++++++++++++++++++---------
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 44b6146..c7e8c88 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2015-05-08  Andreas Arnez  <arnez@linux.vnet.ibm.com>
+
+	* s390-linux-nat.c (fill_gregset): Avoid relying on the PSWA
+	register in the regcache when treating the PSWM register, and vice
+	versa.
+
 2015-05-07  Gary Benson <gbenson@redhat.com>
 
 	* linux-thread-db.c (struct thread_db_info)
diff --git a/gdb/s390-linux-nat.c b/gdb/s390-linux-nat.c
index 9298bcc..4cd3192 100644
--- a/gdb/s390-linux-nat.c
+++ b/gdb/s390-linux-nat.c
@@ -156,19 +156,29 @@ fill_gregset (const struct regcache *regcache, gregset_t *regp, int regno)
 	  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
 	  ULONGEST pswa, pswm;
 	  gdb_byte buf[4];
+	  gdb_byte *pswm_p = (gdb_byte *) regp + S390_PSWM_OFFSET;
+	  gdb_byte *pswa_p = (gdb_byte *) regp + S390_PSWA_OFFSET;
 
-	  regcache_raw_collect (regcache, S390_PSWM_REGNUM, buf);
-	  pswm = extract_unsigned_integer (buf, 4, byte_order);
-	  regcache_raw_collect (regcache, S390_PSWA_REGNUM, buf);
-	  pswa = extract_unsigned_integer (buf, 4, byte_order);
+	  pswm = extract_unsigned_integer (pswm_p, 8, byte_order);
 
 	  if (regno == -1 || regno == S390_PSWM_REGNUM)
-	    store_unsigned_integer ((gdb_byte *) regp + S390_PSWM_OFFSET, 8,
-				    byte_order, ((pswm & 0xfff7ffff) << 32) |
-				    (pswa & 0x80000000));
+	    {
+	      pswm &= 0x80000000;
+	      regcache_raw_collect (regcache, S390_PSWM_REGNUM, buf);
+	      pswm |= (extract_unsigned_integer (buf, 4, byte_order)
+		       & 0xfff7ffff) << 32;
+	    }
+
 	  if (regno == -1 || regno == S390_PSWA_REGNUM)
-	    store_unsigned_integer ((gdb_byte *) regp + S390_PSWA_OFFSET, 8,
-				    byte_order, pswa & 0x7fffffff);
+	    {
+	      regcache_raw_collect (regcache, S390_PSWA_REGNUM, buf);
+	      pswa = extract_unsigned_integer (buf, 4, byte_order);
+	      pswm ^= (pswm ^ pswa) & 0x80000000;
+	      pswa &= 0x7fffffff;
+	      store_unsigned_integer (pswa_p, 8, byte_order, pswa);
+	    }
+
+	  store_unsigned_integer (pswm_p, 8, byte_order, pswm);
 	}
       return;
     }


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]