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

[Dave Anderson]

----- "Cliff Wickman" <cpw at sgi.com> wrote:

> 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
>   ...

I don't know why you don't see per-function arguments:

  crash> bt -f e0000003e0038000
  PID: 10464  TASK: e0000003e0038000  CPU: 0   COMMAND: "bash"
   #0 [BSP:e0000003e00393c0] schedule at a00000010064a130
      (void)
   #1 [BSP:e0000003e0039350] do_wait at a000000100083af0
      (ffffffffffffffff, e, 0, 60000fffffcc780c, 0)
   #2 [BSP:e0000003e00392f8] sys_wait4 at a000000100084000
      (ffffffffffffffff, 60000fffffcc780c, a, 0)
   #3 [BSP:e0000003e00392f8] __ia64_trace_syscall at a00000010000bdd0
    EFRAME: e0000003e003fe40
   ...

> 
> 
> 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?

Never.  The ia64 backtrace code is port of the kernel unwind
code into user space.

Dave