[Crash-utility] GCORE: add directly show backtrace function in crash

[Lei Wen]

Hi Daisuke,

On Tue, Oct 23, 2012 at 2:17 PM, HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com
> wrote:

> From: Lei Wen <adrian.wenl at gmail.com>
> Subject: Re: GCORE: add directly show backtrace function in crash
> Date: Mon, 22 Oct 2012 15:36:47 +0800
>
> > Hi Daisuke,
> >
> > On Mon, Oct 22, 2012 at 3:29 PM, HATAYAMA Daisuke <
> d.hatayama at jp.fujitsu.com
> >> wrote:
> >
> >> From: Lei Wen <adrian.wenl at gmail.com>
> >> Subject: GCORE: add directly show backtrace function in crash
> >> Date: Mon, 22 Oct 2012 12:21:49 +0800
> >>
> >> > Hi Daisuke,
> >> >
> >> > I create a new option "-tT" for gcore, so that it could display bt for
> >> user
> >> > space
> >> > directly inside crash itself, without needing to dump a separated core
> >> file
> >> > image,
> >> > and analyze it in a different gdb env.
> >> >
> >> > The attached patch is directly based on below patch, and verify over
> ARM
> >> > platform.
> >> > http://osdir.com/ml/general/2012-10/msg32677.html
> >> >
> >> > Before use the corresponding gcore command, we need set env in crash
> by:
> >> >
> >> > crash>> gdb set solib-search-path [system lib path]
> >> >
> >> > crash>> gdb file   [user space program symbol file]
> >> >
> >> > crash>> gcore -t [user space thread id]
> >> >
> >> > Thanks,
> >> > Lei
> >>
> >> Hello Lei,
> >>
> >> That must be a useful feature, but I think it's very othogonal to
> >> gcore command...
> >>
> >> Why not releasing your own extension module separately to gcore?
> >>
> >
> > I put this function in gcore, is for gcore already provide the function
> to
> > get
> > the general register for user space thread. If add another module, that
> > part of function seems a little duplicated...
> >
>
> I now understand why you want to add it in gcore.
>
> > Also provide the gcore the capability to either dump into a core file
> > or directly display, user may have more choice over this. :)
> >
>
> But, users then need to do more work such as loading application's
> symbol files. There seems not so big difference.
>
> gdb has one symbol space only. If you load applications's symbols, it
> can override kernel symbols. Then, gcore might behave abnormally. Can
> users reset the loading of applications' symbols in any feature of
> gdb?
>

Good question!
However I am not a gdb expert... Hope someone here could give a solution...
Also a silly question, since kernel runs well with user symbol, why gdb
could not live with the chaos?


> 32-bit compability mode support? On x86-64 task can be running in
> 32-bit comparitbility mode. If so, gdb backtrace need to do the work
> in 32-bit mode, I think. Does the current version covers this?
>
>
No idea really...

Thanks,
Lei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20121023/cd76fc5a/attachment.htm>