FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 01-30-2009, 07:05 PM
Cliff Wickman
 
Default bt -f (ia64)

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?

Thanks.
-Cliff

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-30-2009, 07:36 PM
Dave Anderson
 
Default bt -f (ia64)

----- "Cliff Wickman" <cpw@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?
>
> Thanks.
> -Cliff

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

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-30-2009, 09:42 PM
Cliff Wickman
 
Default bt -f (ia64)

On Fri, Jan 30, 2009 at 03:36:00PM -0500, Dave Anderson wrote:
>
> ----- "Cliff Wickman" <cpw@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@sgi.com
(651) 683-3824

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-02-2009, 12:33 PM
Dave Anderson
 
Default bt -f (ia64)

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

> On Fri, Jan 30, 2009 at 03:36:00PM -0500, Dave Anderson wrote:
> >
> > ----- "Cliff Wickman" <cpw@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

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 07:12 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org