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

On Fri, Jan 30, 2009 at 03:36:00PM -0500, Dave Anderson wrote: > > ----- "Cliff Wickman" <cpw(a)sgi.com&gt; 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?