----- "Cliff Wickman" <cpw@xxxxxxx> wrote:
> 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
> ...
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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
