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

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(-)

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);

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.