[Crash-utility] Fix bug of list -h

[Petr Tesarik]

Dne Pá 1. června 2012 05:52:17 qiaonuohan napsal(a):
> Hello Dave,

Hello qiaonuohan,

> When investigating list command, I found the "-h" is involved but not
> discussed in help page. And then I tried to use, but I find some
> problems with it.

In a previous post, I pointed out that "list -h" is undocumented and hardly 
useful. In fact, there is a comment in tools.c that explains "list -h":

 *  If the structures are linked using list_head structures, the -h or -H 
 *  options must be used.  In that case, the "start" address is:
 *  a pointer to  the embedded list_head structure (-h), or a pointer to a 
 *  LIST_HEAD() structure (-H).

This matches exactly what crash actually does, although I can't find a use 
case for that.

> The first, I made patch to show it. The "ld->start" should be the
> pointer to the structure list_head.
> 
> And the second one, I am not sure about the reason why you don't
> display the node related to the address user input. I will take the
> tasks of task_struct as an example.
> 
> crash> task_struct.tasks ffff8800371a0ac0
>    tasks = {
>      next = 0xffffffff81a8d468,
>      prev = 0xffff88004a9e0f88
>    }
> crash> list task_struct.tasks -s task_struct.tasks -h ffff8800371a0ac0
> ffffffff81a8d020
>    tasks = {
>      next = 0xffff88004eaf1908,
>      prev = 0xffff8800371a0f08
>    }

This doesn't match my experience. If I try to use the address of the 
containing task_struct with "list -h", I'll get invalid output. I'd have to 
use the address of the embedded list_head, but then it also includes the 
structure in which that list_head was embedded. E.g. on my 32-bit laptop I 
get:

crash> task_struct.tasks 0xeede04f0
  tasks = {
    next = 0xd79d6f20, 
    prev = 0xd55e6220
  }
crash> struct -o task_struct.tasks
struct task_struct {
   [432] struct list_head tasks;
}
crash> list task_struct.tasks -s task_struct.tasks -h 0xeede04f0+432
eede04f0
  tasks = {
    next = 0xd79d6f20, 
    prev = 0xd55e6220
  }
d79d6d70
  tasks = {
    next = 0xc32c5320, 
    prev = 0xeede06a0
  }
...

Note that the first element in the list (the one which contains the starting 
list_head) is included.

Based on the above, I'm afraid don't quite get the intended goal of your 
patch.

Petr Tesarik