8:37 a.m.
----- Original Message -----
Hi Daisuke,
On Tue, Sep 18, 2012 at 8:19 AM, HATAYAMA Daisuke <
d.hatayama(a)jp.fujitsu.com > wrote:
From: Dave Anderson < anderson(a)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(a)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(a)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(a)suse.cz >
>> Tested-by: Toshiyuki Okajima < toshi.okajima(a)jp.fujitsu.com >
>> Signed-off-by: Christoph Hellwig < hch(a)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