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 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

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 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. Thanks. HATAYAMA, Daisuke

----- Original Message ----- Probably... It is possible to invoke the gdb "add-symbol-file" file command giving it the name of the user's executable and its starting address as shown by the "vm" command, and then the embedded gdb will have a copy of the executable's symbol values and debuginfo data. But the top-level crash utility does not store those symbols. I've done that in order to display user program data, say for example, the crash utility's program_context data structure: crash> vm PID: 2179 TASK: ffff8801f4171710 CPU: 1 COMMAND: "crash" MM PGD RSS TOTAL_VM ffff88020e56d080 ffff8801fbcba000 182636k 331376k VMA START END FLAGS FILE ffff8801deae9a50 400000 a0c000 8001875 /var/CVS/crash/crash ffff8801deae9420 c0c000 c2d000 8101873 /var/CVS/crash/crash ffff8801de8da580 c2d000 dc3000 100073 ffff8801deafcd10 2935000 60ca000 100073 ffff8801de8daa50 3550000000 3550020000 8000875 /usr/lib64/ld-2.15.so ffff8801de8da0b0 355021f000 3550220000 8100871 /usr/lib64/ld-2.15.so ... crash> add-symbol-file /var/CVS/crash/crash 0x400000 add symbol table from file "/var/CVS/crash/crash" at .text_addr = 0x400000 Reading symbols from /var/CVS/crash/crash...done. crash> crash> whatis program_context struct program_context { char *program_name; char *program_path; char *program_version; char *gdb_version; char *prompt; long long unsigned int flags; char *namelist; char *dumpfile; char *live_memsrc; ... crash> p &program_context $11 = (struct program_context *) 0xc46ee0 crash> struct -u program_context 0xc46ee0 struct program_context { program_name = 0x7fff3d6f0806 "crash", program_path = 0x7fff3d6f0804 "./crash", program_version = 0x81d2b0 "6.1.0rc14", gdb_version = 0x8927e9 "7.3.1", prompt = 0x294acb0 "crash> ", flags = 879609304517639, namelist = 0x29404a0 "/usr/lib/debug/lib/modules/3.5.3-1.fc17.x86_64/vmlinux", dumpfile = 0x0, live_memsrc = 0x7c72b8 "/dev/crash", ... And you could query gdb for the user-space text addresses: crash> p &x86_64_init $18 = (void (*)(int)) 0x48c770 <x86_64_init> crash> p &cmd_vm $19 = (void (*)(void)) 0x425d00 <cmd_vm> crash> There's no way I would consider polluting the per-arch backtrace functions with any kind of user-space support. But it might be interesting to try to do something in an extension module. Dave

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