[PATCH] powerpc: Fix xmon ml/mz commands to work with 64-bit values

[PATCH] powerpc: Fix xmon ml/mz commands to work with 64-bit values

[Josh Boyer]

The ml and and mz commands in xmon currently only work on 32-bit values.
This leads to odd issues when trying to use them on a ppc64 machine.  If
one specified 64-bit addresses to mz, it would loop on the same output
indefinitely.  The ml command would fail to find any 64-bit values in a
memory range, even though one could clearly see them present with the d
command.

This adds a small function that mimics GETWORD, but works for 64-bit
values.  The data types involved in these commands are also changed to
'unsigned long' instead of just 'unsigned'.

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/xmon/xmon.c |   47 ++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 38 insertions(+), 9 deletions(-)

Index: linux-2.6/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-2.6.orig/arch/powerpc/xmon/xmon.c
+++ linux-2.6/arch/powerpc/xmon/xmon.c
@@ -2257,14 +2257,40 @@ memdiffs(unsigned char *p1, unsigned cha
 		printf("Total of %d differences\n", prt);
 }
 
-static unsigned mend;
-static unsigned mask;
+static unsigned long mend;
+static unsigned long mask;
+
+/* This is mimics GETWORD but works for 64-bit values. */
+static inline unsigned long xmon_getval(unsigned char *val)
+{
+	unsigned long word1 = 0, word2 = 0;
+	unsigned long size = sizeof(unsigned long);
+	int i;
+	int bits = 24;
+
+	for (i = 0; i < 4; i++) {
+		word1 += val[i] << bits;
+		bits -= 8;
+	}
+	if (size > 4) {
+		bits = 24;
+		for (i = 4; i < 8; i++) {
+			word2 += val[i] << bits;
+			bits -= 8;
+		}
+		word1 = word1 << 32;
+		word2 = word2 & 0x00000000ffffffff;
+		word1 = word1 | word2;
+	}
+	return word1;
+}
 
 static void
 memlocate(void)
 {
-	unsigned a, n;
-	unsigned char val[4];
+	unsigned long a, n;
+	unsigned char val[sizeof(unsigned long)];
+	int size = sizeof(unsigned long);
 
 	last_cmd = "ml";
 	scanhex((void *)&mdest);
@@ -2280,10 +2306,10 @@ memlocate(void)
 		}
 	}
 	n = 0;
-	for (a = mdest; a < mend; a += 4) {
-		if (mread(a, val, 4) == 4
-			&& ((GETWORD(val) ^ mval) & mask) == 0) {
-			printf("%.16x:  %.16x\n", a, GETWORD(val));
+	for (a = mdest; a < mend; a += size) {
+		if (mread(a, val, size) == size
+			&& ((xmon_getval(val) ^ mval) & mask) == 0) {
+			printf("%.16lx:  %.16lx\n", a, xmon_getval(val));
 			if (++n >= 10)
 				break;
 		}
@@ -2297,7 +2323,7 @@ static void
 memzcan(void)
 {
 	unsigned char v;
-	unsigned a;
+	unsigned long a;
 	int ok, ook;
 
 	scanhex(&mdest);

Re: [PATCH] powerpc: Fix xmon ml/mz commands to work with 64-bit values

[Benjamin Herrenschmidt]

On Fri, 2011-04-08 at 08:18 -0400, Josh Boyer wrote:
> The ml and and mz commands in xmon currently only work on 32-bit values.
> This leads to odd issues when trying to use them on a ppc64 machine.  If
> one specified 64-bit addresses to mz, it would loop on the same output
> indefinitely.  The ml command would fail to find any 64-bit values in a
> memory range, even though one could clearly see them present with the d
> command.
> 
> This adds a small function that mimics GETWORD, but works for 64-bit
> values.  The data types involved in these commands are also changed to
> 'unsigned long' instead of just 'unsigned'.
> 
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

Well if you're going to mimic GETWORD, why not replace it everywhere ?

Or just do that :-)

#if BITS_PER_LONG == 32
#define GETLONG(v)	GETWORD(v)
#else
#define GETLONG(v)	((GETWORD(v) << 32) | GETWORD(v + 4))
#endif

Cheers,
Ben.
 
>  static void
>  memlocate(void)
>  {
> -	unsigned a, n;
> -	unsigned char val[4];
> +	unsigned long a, n;
> +	unsigned char val[sizeof(unsigned long)];
> +	int size = sizeof(unsigned long);
>  
>  	last_cmd = "ml";
>  	scanhex((void *)&mdest);
> @@ -2280,10 +2306,10 @@ memlocate(void)
>  		}
>  	}
>  	n = 0;
> -	for (a = mdest; a < mend; a += 4) {
> -		if (mread(a, val, 4) == 4
> -			&& ((GETWORD(val) ^ mval) & mask) == 0) {
> -			printf("%.16x:  %.16x\n", a, GETWORD(val));
> +	for (a = mdest; a < mend; a += size) {
> +		if (mread(a, val, size) == size
> +			&& ((xmon_getval(val) ^ mval) & mask) == 0) {
> +			printf("%.16lx:  %.16lx\n", a, xmon_getval(val));
>  			if (++n >= 10)
>  				break;
>  		}
> @@ -2297,7 +2323,7 @@ static void
>  memzcan(void)
>  {
>  	unsigned char v;
> -	unsigned a;
> +	unsigned long a;
>  	int ok, ook;
>  
>  	scanhex(&mdest);

Re: [PATCH] powerpc: Fix xmon ml/mz commands to work with 64-bit values

[Benjamin Herrenschmidt]

On Wed, 2011-05-04 at 14:43 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2011-04-08 at 08:18 -0400, Josh Boyer wrote:
> > The ml and and mz commands in xmon currently only work on 32-bit values.
> > This leads to odd issues when trying to use them on a ppc64 machine.  If
> > one specified 64-bit addresses to mz, it would loop on the same output
> > indefinitely.  The ml command would fail to find any 64-bit values in a
> > memory range, even though one could clearly see them present with the d
> > command.
> > 
> > This adds a small function that mimics GETWORD, but works for 64-bit
> > values.  The data types involved in these commands are also changed to
> > 'unsigned long' instead of just 'unsigned'.
> > 
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> 
> Well if you're going to mimic GETWORD, why not replace it everywhere ?
> 
> Or just do that :-)
> 
> #if BITS_PER_LONG == 32
> #define GETLONG(v)	GETWORD(v)
> #else
> #define GETLONG(v)	((GETWORD(v) << 32) | GETWORD(v + 4))
> #endif

Note that Paul mentions the whole thing is pretty much useless
anyways :-)

It's a remnant of the xmon code running in "foreign" environments such
as little endian he reckons. You could probably just dereference the
value.

Now it has the side effect of potentially avoiding alignment interrupts
which might be a "good thing" but then, we don't do it everywhere in
xmon so it's pointless.

Cheers,
Ben.