[Crash-utility] enhance bt command

[Ming Zhang]

On Mon, 2008-03-03 at 12:51 -0500, Dave Anderson wrote:
> Ming Zhang wrote:
> > On Mon, 2008-03-03 at 11:19 -0500, Dave Anderson wrote:
> >> Ming Zhang wrote:
> >>> On Mon, 2008-03-03 at 09:19 -0500, Dave Anderson wrote:
> >>>> I'm not sure whether cluttering the bt -f command output would
> >>>> be all that worthwhile, but I'm thinking that this request may have
> >>>> some merit with respect to the "rd" command.  Currently the
> >>>> "rd -s" option recognizes and translates kernel symbols that it
> >>>> finds in the raw memory output.  Maybe something like a "-S"
> >>>> option could do that -- plus also recognize kernel virtual memory
> >>>> addresses that come from the slab cache, and alternatively display
> >>>> the slab cache namestring in some recognizable manner, i.e. bracketed,
> >>>> or something like to that effect.
> >>>>
> >>>> Then since "bt -f" displays the block of memory associated with
> >>>> each stack frame, you could easily transfer the stack address
> >>>> to a "rd -S [stack-address] [count]" command.
> >>> yes. it will be great if we can have a rd -S!
> >>>
> >> Apply the attached patch and see what you think.  The "rd -S"
> >> option supplements "-s" by also recognizing memory from slab
> >> caches -- and alternatively displaying the slab cache name
> >> in brackets.
> >>
> > 
> > this is what it looks like
> > 
> >      10078b2ba30:  vprintk+498      .LC391+195657    
> >      10078b2ba40:  0000000000000471 [size-32]        
> >      10078b2ba50:  000000000000016e 0000000000000001 
> >      10078b2ba60:  0000000000000005 [kmem_cache]     
> >      10078b2ba70:  000000000000003c [size-1024]      
> >      10078b2ba80:  [kmem_cache]     0000000000000000 
> >      10078b2ba90:  0000000000000001 00000000801108a1 
> > 
> > 
> > [raw value: cache name] will be better
> 
> That would take up too much space, especially on a 32-bit
> machine's display, which shows 4 addresses per line.
> 
> > 
> > strangely, not all the value is correct. i am looking at it.
> 
> I'm not sure what you mean by them not being correct, but
> if you run "kmem -s [address]", it should show the samec
> slab cache container (since it uses the same facility).
> For example:


my English sucks...

this is what i got. my side size-512 or size-1024 also works. just stuff
like dentry cache or inode cache does not work.


crash> rd 10078b2bca0 2
     10078b2bca0:  000001007877c8d4 00000100710fd5c8   ..wx.......q....
crash> rd -S 10078b2bca0 2
     10078b2bca0:  [dentry_cache]   00000100710fd5c8 
crash> kmem -s 10078b2bca0
kmem: address is not allocated in slab subsystem: 10078b2bca0




> 
> crash> rd d799df80 4
> d799df80:  00000004 c0470395 d799dfa4 ca9ec8c0   ......G.........
> crash> rd -S d799df80 4
> d799df80:  00000004 vfs_read+159 [size-4096] [filp]
> crash> kmem -s d799dfa4
> CACHE    NAME                 OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE
> dff74e80 size-4096               4096        215       233    233     4k
> SLAB      MEMORY    TOTAL  ALLOCATED  FREE
> c64f9e20  d799d000      1          1     0
> FREE / [ALLOCATED]
>    [d799dfa4]
> crash> kmem -s ca9ec8c0
> CACHE    NAME                 OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE
> dfc7a280 filp                     192       4271      4580    229     4k
> SLAB      MEMORY    TOTAL  ALLOCATED  FREE
> ca9ec000  ca9ec080     20          9    11
> FREE / [ALLOCATED]
>    [ca9ec8c0]
> crash>
> 
> Dave
> 
> 
-- 
Ming Zhang


@#$%^ purging memory... (*!%
http://blackmagic02881.wordpress.com/
http://www.linkedin.com/in/blackmagic02881
--------------------------------------------