[Crash-utility] [PATCH]: gcore extension, anonymous union in inode struct

[Lei Wen]

Hi Daisuke and Dave,

On Mon, Sep 24, 2012 at 8:18 AM, HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com
> wrote:

> From: Lei Wen <adrian.wenl at gmail.com>
> Subject: Re: [Crash-utility] [PATCH]: gcore extension, anonymous union in
> inode struct
> Date: Fri, 21 Sep 2012 16:47:41 +0800
>
> > Hi  Daisuke,
> >
>
> Hello,
>
> > On Tue, Sep 18, 2012 at 8:19 AM, HATAYAMA Daisuke <
> d.hatayama at jp.fujitsu.com
> >> wrote:
> >
> >> From: Dave Anderson <anderson at redhat.com>
> >> Subject: Re: [Crash-utility] [PATCH]: gcore extension, anonymous union
> in
> >> inode struct
> >> Date: Tue, 11 Sep 2012 08:50:32 -0400
> >>
> >> >
> >> >
> >> > ----- Original Message -----
> >> >> From: Per Fransson <per.fransson.ml at gmail.com>
> >> >> Subject: [Crash-utility] [PATCH]: gcore extension, anonymous union in
> >> >> inode struct
> >> >> Date: Wed, 5 Sep 2012 12:29:43 +0200
> >> >>
> >> >> > Hi Crash people,
> >> >> >
> >> >> > The gcore extension fails on the 3.4 kernel I'm using. It attempts
> to
> >> >> > find the offset of a member within the inode struct, but the member
> >>  is
> >> >> > part of an anonymous union. This patch fixes the problem for me.
> >> >> >
> >> >> > Regards,
> >> >> > Per
> >> >>
> >> >> Hello Per,
> >> >>
> >> >> Thanks for reporting that. According to git repository, this was
> >> >> changed by the following commit at the v3.1 period.
> >> >>
> >> >> $ git describe a78ef704a8dd430225955f0709b22d4a6ba21deb
> >> >> v3.1-8569-ga78ef70
> >> >>
> >> >> $ git log -1 a78ef704a8dd430225955f0709b22d4a6ba21deb
> >> >> commit a78ef704a8dd430225955f0709b22d4a6ba21deb
> >> >> Author: Miklos Szeredi <mszeredi at suse.cz>
> >> >> Date:   Fri Oct 28 14:13:30 2011 +0200
> >> >>
> >> >>     vfs: protect i_nlink
> >> >>
> >> >>     Prevent direct modification of i_nlink by making it const and
> >> adding a
> >> >>     non-const __i_nlink alias.
> >> >>
> >> >>     Signed-off-by: Miklos Szeredi <mszeredi at suse.cz>
> >> >>     Tested-by: Toshiyuki Okajima <toshi.okajima at jp.fujitsu.com>
> >> >>     Signed-off-by: Christoph Hellwig <hch at lst.de>
> >> >>
> >> >> The patch appears fine to me so I'll apply it.
> >> >>
> >> >> Thanks.
> >> >> HATAYAMA, Daisuke
> >> >
> >> > Hi Daisuke,
> >> >
> >> > Will you be updating the crash-gcore-command tar.gz package?
> >> >
> >>
> >> Hello Dave,
> >>
> >> I have another gcore test plan soon. I'm going to update this change
> >> together with it. Please wait for a few weeks.
> >>
> >>
> > I have a curious question for the gcore. Current what we could do with
> > gcore is to generate a core dump image, and then be parsed with external
> > gdb along with user space lib symbol.
> >
> > Could it be possible that integrating the whole process into crash
> itself.
> > That is without referring to external gdb's help, crash itself could
> print
> > out
> > the call stack from user to kernel. I think it would be more convenient
> like
> > it current is.
> >
> > Do you think implement it would be complex?
> >
>
> As Dave suggests, I think it a reasonable way to do is do it in an
> extension module independently of crash utility (so integrated gdb),
> because my understanding is that gdb can manage only one symbol space
> so symbol conflicts may happen. Also, basically kernel crash dump
> typically have physical memory shape, and crash utility does
> virtual-to-physical address translation. I think it possible to do it
> in an independent extnesion module that manages memory view, symbols
> and other debugging information locally.
>
> Thanks.
> HATAYAMA, Daisuke
>
>
I think display backtrace inside extension module could already fulfill
the need, and it is true that we shouldn't pollute crash's symbol context.

I would try to dig further to see what could we benefit from this inside
bt. :)

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