The reason debuggers add an ASCII dump to other types of memory dumps
is to give the user visual reference points in the case that ASCII
strings are adjacent to other structures or element.  For example,
when examining the task_struct structure one can look for the comm[]
string and use it to locate other important elements.

ASCII strings do not have endianess, they exist in memory in the same
order regardless of CPU endianess. ASCII strings are, by definition,
human readable and so should be presented in a human readable format.

For these reasons, the supplemental ASCII dump does not re-order
the strings from memory to match the endianess of the corresponding
16, 32, or 64 bit words. That would make the ASCII dump much less
useful.

Signed-off-by: Douglas Miller <dougm...@linux.vnet.ibm.com>
---
 arch/powerpc/xmon/xmon.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 57503cd..f8f0f35 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2366,7 +2366,12 @@ static void dump_by_size(unsigned long addr, long count, 
int size)
 
                        printf("%0*lx", size * 2, val);
                }
-               printf("\n");
+               printf("  |");
+               for (j = 0; j < 16; ++j) {
+                       val = temp[j];
+                       putchar(' ' <= val && val <= '~' ? val : '.');
+               }
+               printf("|\n");
        }
 }
 
-- 
1.7.1

Reply via email to