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

Hi Daisuke and Dave, On Mon, Sep 24, 2012 at 8:18 AM, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com > From: Lei Wen <adrian.wenl(a)gmail.com&gt; > 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(a)jp.fujitsu.com > >> > > >> From: Dave Anderson <anderson(a)redhat.com&gt; > >> 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(a)gmail.com&gt; > >> >> 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(a)suse.cz&gt; > >> >> 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(a)suse.cz&gt; > >> >> Tested-by: Toshiyuki Okajima <toshi.okajima(a)jp.fujitsu.com&gt; > >> >> Signed-off-by: Christoph Hellwig <hch(a)lst.de&gt; > >> >> > >> >> 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