On Fri, Jan 30, 2009 at 03:36:00PM -0500, Dave Anderson wrote:
>
> ----- "Cliff Wickman" <cpw@xxxxxxx> 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@xxxxxxx
(651) 683-3824
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
