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

[Dave Anderson]

----- Original Message -----
> Hi Daisuke,
> 
> 
> 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?

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


> 
> Thanks,
> Lei