[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> 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(a)sgi.com
(651) 683-3824