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

[HATAYAMA Daisuke]

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