----- Original Message -----
> Hi Daisuke,
>
>
> On Tue, Sep 18, 2012 at 8:19 AM, HATAYAMA Daisuke <
> d.hatayama@xxxxxxxxxxxxxx > wrote:
>
>
> From: Dave Anderson < anderson@xxxxxxxxxx >
> Subject: Re: [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@xxxxxxxxx >
> >> Subject: [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@xxxxxxx >
> >> 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@xxxxxxx >
> >> Tested-by: Toshiyuki Okajima < toshi.okajima@xxxxxxxxxxxxxx >
> >> Signed-off-by: Christoph Hellwig < hch@xxxxxx >
> >>
> >> 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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
