[Crash-utility] Re: bt -f (ia64)

[Cliff Wickman]

On Fri, Jan 30, 2009 at 03:36:00PM -0500, Dave Anderson wrote:
> 
> ----- "Cliff Wickman" <cpw at sgi.com> wrote:
> > Hi Dave,
> > 
> > In using crash yesterday on an ia64 dump I found that "bt -f" did
> > not show contents of the stack. Neither memory stack nor stacked registers.
> > (It does show the "bsp" pointer to backing storage, which helps)
> > 
> > It must have displayed the stacks' contents in the past, as the help for
> > bt says:
> >        -f  display all stack data contained in a frame; this option can be
> >            used to determine the arguments passed to each function; on ia64,
> >            the argument register contents are dumped.
> > 
> > I don't find any discussion on this subject.
> > Can you tell me anything about the status of it?
> 
> As the help page states, the ia64 "bt -f" option dumps the arguments
> to each function.  On the other architectures, it dumps the data in
> each stack frame as an aid in finding the function arguments.
>  
> If you want to look at raw ia64 stack contents, use "bt -r".

bt -r shows the memory stack, but not per-function.
And to see function arguments we need the register stack.
BSP is the address of register stack backing storage, but it would be
nice if -f broke out both the register and memory stack frames.

crash> bt -f e00000b8740a0000
PID: 32111  TASK: e00000b8740a0000  CPU: 4   COMMAND: "bash"
 #0 [BSP:e00000b8740a1458] schedule at a0000001006e4170
 #1 [BSP:e00000b8740a13a8] do_wait at a0000001000a2e50
 #2 [BSP:e00000b8740a1330] sys_wait4 at a0000001000a3590
 #3 [BSP:e00000b8740a1330] ia64_ret_from_syscall at a00000010000c600
  EFRAME: e00000b8740afe40
  ...


Something like this:
>> trace -f 0xe00000b433c00000
================================================================
STACK TRACE FOR TASK: 0xe00000b433c00000 (bash)

 0 schedule+0x10ac [0xa0000001006e416c]

   RA=0xa0000001000a2e50, PFS=0xa9d, CFM=0x8
   SP=0xe00000b433c0fdf0, MSIZE=0
   BSP=0xe00000b433c01458, BSIZE=0

 1 do_wait+0x44c [0xa0000001000a2e4c]

   RA=0xa0000001000a3590, PFS=0x795, CFM=0xa9d
   SP=0xe00000b433c0fdf0, MSIZE=8
   BSP=0xe00000b433c013a8, BSIZE=21

   REGISTER FRAME:

     32: 0x6000000007bb7a88     33: 0x000000000001b789
     34: 0x0000000000000001     35: 0x0000000000000006
     36: 0x000000000001b789     37: 0x0000000000000098
     38: 0x0000000000000000     39: 0x0000000000000000
     40: 0x0000000000000000     41: 0x0000000000000000
   rnat: 0x0000000000000000     42: 0x0000000000000000
     43: 0x0000000000000000     44: 0x0000000000000000
     45: 0x0000000000000000     46: 0x6000000007bb7ad8
     47: 0x0000000000000000     48: 0x6000000007bb6138
     49: 0x0000000000000051     50: 0x6000000007bb7a50
     51: 0x6000000007bb7a50

   MEMORY FRAME:

   e00000b433c0fdf0: e00000b433c01680  089aa0aaaa5a9669  
   e00000b433c0fe00: 600fffffffd6e7ec  0000000000000000  
   e00000b433c0fe10: 00000000fffffe00  0000000000000000  
   e00000b433c0fe20: e00000b433c00000  a0000001008f3450  

 2 sys_wait4+0x12c [0xa0000001000a358c]

Didn't the "old" ia64 unwind do something like that?

-Cliff
-- 
Cliff Wickman
Silicon Graphics, Inc.
cpw at sgi.com
(651) 683-3824