| Message ID | 1488205694-13337-1-git-send-email-dougmill@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 8ec26c25c33d21468a8b39722337463550b15e5b |
| Headers | show |
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"); } }
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 <dougmill@linux.vnet.ibm.com> --- arch/powerpc/xmon/xmon.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)