Re: [Crash-utility] [PATCH] raw_data_dump: display only 8/16/32 bits if requested

2020-04-02 Thread Dominique Martinet 
Dave Anderson wrote on Thu, Apr 02, 2020:
> Yes, let's do that -- queued for crash-7.2.9:
> 
>   
> https://github.com/crash-utility/crash/commit/8c28b5625505241d80ec5162f58ccc563e5e59f9

Thanks!
Checked both commits, small wording difference looks good to me.

-- 
Dominique


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] [PATCH] raw_data_dump: display only 8/16/32 bits if requested

2020-04-02 Thread Dave Anderson 



- Original Message -
> Previously, calling raw_data_dump() with e.g. len 4 on 64bit systems
> would dump 8 bytes anyway, making it hard to tell what one wants to see.
> 
> For example, with task_struct.rt_priority a uint32.
> before patch:
> crash> struct -r task_struct.rt_priority 8d9b36186180
> 8d9b361861dc:  9741dec00063c.A.
> 
> after patch:
> crash-patched> struct -r task_struct.rt_priority 8d9b36186180
> 8d9b361861dc:  0063  c...
> ---
> 
> Here's the promised follow-up.
> 
> Two remarks:
>  - I wasn't sure about an explicit DISPLAY_64 flag, but if we're 32bit
> and want to print 8 bytes it is just as likely to be two entities than
> a single one so it makes more sense to leave default to me.
>  - I wasn't sure on what to do if someone wants to print some odd size,
> e.g. 6 bits? Should that be DISPLAY_8 anyway?
> I tried on some bitmap and it looks like raw_data_dump is called with 8
> anyway even if the bitmap part is less than 8, I'm not sure this can
> ever be called with weird values, so probably best left as is.

Yes, let's do that -- queued for crash-7.2.9:

  
https://github.com/crash-utility/crash/commit/8c28b5625505241d80ec5162f58ccc563e5e59f9

Thanks,
  Dave



> Thanks!
> 
>  memory.c | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/memory.c b/memory.c
> index 4f7b6a0..ccc2944 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -2113,6 +2113,7 @@ raw_data_dump(ulong addr, long count, int symbolic)
>   long wordcnt;
>   ulonglong address;
>   int memtype;
> + ulong flags = HEXADECIMAL;
>  
>   switch (sizeof(long))
>   {
> @@ -2132,6 +2133,22 @@ raw_data_dump(ulong addr, long count, int symbolic)
>   break;
>   }
>  
> + switch (count)
> + {
> + case SIZEOF_8BIT:
> + flags |= DISPLAY_8;
> + break;
> + case SIZEOF_16BIT:
> + flags |= DISPLAY_16;
> + break;
> + case SIZEOF_32BIT:
> + flags |= DISPLAY_32;
> + break;
> + default:
> + flags |= DISPLAY_DEFAULT;
> + break;
> + }
> +
>   if (pc->curcmd_flags & MEMTYPE_FILEADDR) {
>   address = pc->curcmd_private;
>   memtype = FILEADDR;
> @@ -2144,7 +2161,7 @@ raw_data_dump(ulong addr, long count, int symbolic)
>   }
>  
>   display_memory(address, wordcnt,
> - HEXADECIMAL|DISPLAY_DEFAULT|(symbolic ? SYMBOLIC : ASCII_ENDLINE),
> + flags|(symbolic ? SYMBOLIC : ASCII_ENDLINE),
>   memtype, NULL);
>  }
>  
> --
> 2.26.0
> 
> 
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
> 

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

[Crash-utility] [PATCH] raw_data_dump: display only 8/16/32 bits if requested

2020-04-02 Thread Dominique Martinet 
Previously, calling raw_data_dump() with e.g. len 4 on 64bit systems
would dump 8 bytes anyway, making it hard to tell what one wants to see.

For example, with task_struct.rt_priority a uint32.
before patch:
crash> struct -r task_struct.rt_priority 8d9b36186180
8d9b361861dc:  9741dec00063c.A.

after patch:
crash-patched> struct -r task_struct.rt_priority 8d9b36186180
8d9b361861dc:  0063  c...
---

Here's the promised follow-up.

Two remarks:
 - I wasn't sure about an explicit DISPLAY_64 flag, but if we're 32bit
and want to print 8 bytes it is just as likely to be two entities than
a single one so it makes more sense to leave default to me.
 - I wasn't sure on what to do if someone wants to print some odd size,
e.g. 6 bits? Should that be DISPLAY_8 anyway?
I tried on some bitmap and it looks like raw_data_dump is called with 8
anyway even if the bitmap part is less than 8, I'm not sure this can
ever be called with weird values, so probably best left as is.

Thanks!

 memory.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/memory.c b/memory.c
index 4f7b6a0..ccc2944 100644
--- a/memory.c
+++ b/memory.c
@@ -2113,6 +2113,7 @@ raw_data_dump(ulong addr, long count, int symbolic)
long wordcnt;
ulonglong address;
int memtype;
+   ulong flags = HEXADECIMAL;
 
switch (sizeof(long))
{
@@ -2132,6 +2133,22 @@ raw_data_dump(ulong addr, long count, int symbolic)
break;
}
 
+   switch (count)
+   {
+   case SIZEOF_8BIT:
+   flags |= DISPLAY_8;
+   break;
+   case SIZEOF_16BIT:
+   flags |= DISPLAY_16;
+   break;
+   case SIZEOF_32BIT:
+   flags |= DISPLAY_32;
+   break;
+   default:
+   flags |= DISPLAY_DEFAULT;
+   break;
+   }
+
if (pc->curcmd_flags & MEMTYPE_FILEADDR) {
address = pc->curcmd_private;
memtype = FILEADDR;
@@ -2144,7 +2161,7 @@ raw_data_dump(ulong addr, long count, int symbolic)
}
 
display_memory(address, wordcnt, 
-   HEXADECIMAL|DISPLAY_DEFAULT|(symbolic ? SYMBOLIC : ASCII_ENDLINE),
+   flags|(symbolic ? SYMBOLIC : ASCII_ENDLINE),
memtype, NULL);
 }
 
-- 
2.26.0


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility