Hi Daisuke and Dave, <div class="gmail_quote">On Mon, Sep 24, 2012 at 8:18 AM, HATAYAMA Daisuke <<a href="mailto:d.hatayama@jp.fujitsu.com" target="_blank">d.hatayama@jp.fujitsu.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Lei Wen <<a href="mailto:adrian.wenl@gmail.com">adrian.wenl@gmail.com</a>> <div class="im">Subject: Re: [Crash-utility] [PATCH]: gcore extension, anonymous union in inode struct </div>Date: Fri, 21 Sep 2012 16:47:41 +0800 > Hi Daisuke, > Hello, <div><div class="h5"> > On Tue, Sep 18, 2012 at 8:19 AM, HATAYAMA Daisuke <<a href="mailto:d.hatayama@jp.fujitsu.com">d.hatayama@jp.fujitsu.com</a> >> wrote: > >> From: Dave Anderson <<a href="mailto:anderson@redhat.com">anderson@redhat.com</a>> >> 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 <<a href="mailto:per.fransson.ml@gmail.com">per.fransson.ml@gmail.com</a>> >> >> 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 <<a href="mailto:mszeredi@suse.cz">mszeredi@suse.cz</a>> >> >> 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 <<a href="mailto:mszeredi@suse.cz">mszeredi@suse.cz</a>> >> >> Tested-by: Toshiyuki Okajima <<a href="mailto:toshi.okajima@jp.fujitsu.com">toshi.okajima@jp.fujitsu.com</a>> >> >> Signed-off-by: Christoph Hellwig <<a href="mailto:hch@lst.de">hch@lst.de</a>> >> >> >> >> 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? > </div></div>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 </blockquote></div> <div>I think display backtrace inside extension module could already fulfill</div><div>the need, and it is true that we shouldn't pollute crash's symbol context.</div><div> </div><div>I would try to dig further to see what could we benefit from this inside bt. :)</div><div> </div><div>Thanks,</div><div>Lei</div>