Re: [Crash-utility] [Patch] linux-2.6.22 on i386
Hi Dave,
2007/07/25 10:28:04 -0400, Dave Anderson <anderson(a)redhat.com> wrote:
> Here is the patch for solving the problem. If the array number is
not
> taken, the crash utility assumes that it is the defined value NR_CPUS.
> Or, should get_array_length() be fixed to get the array number from
> init/main.c ?
>
Ken'ichi -- thanks for tracking that down.
I don't see how get_array_length() can be "fixed" in this case -- if the
vmlinux file doesn't have the info, it doesn't have it. I'm not sure
what you mean by getting it from init/main.c?
Sorry for my insufficient explanation.
On linux-2.6.22, the external declaration of i386's __per_cpu_offset[]
is in include/asm-i386/percpu.h, and the definition of __per_cpu_offset[]
is in init/main.c:
unsigned long __per_cpu_offset[NR_CPUS] __read_mostly;
There are their debugging information in the dwarf section, and the
definition's one includes the array length.
I explain by following output of the dwarfdump command.
* The debugging information of "extern unsigned long __per_cpu_offset[];"
There is not the attribute DW_AT_upper_bound and the crash utility cannot
get the array number.
<1><32685> DW_TAG_variable
DW_AT_name __per_cpu_offset
DW_AT_decl_file 83 include/asm/percpu.h
DW_AT_decl_line 48
DW_AT_type <32674>
DW_AT_external yes(1)
DW_AT_declaration yes(1)
<1><32674> DW_TAG_array_type
DW_AT_sibling <32685>
DW_AT_type <83>
<2><32683> DW_TAG_subrange_type
* The debugging information of "unsigned long __per_cpu_offset[NR_CPUS]
__read_mostly;"
There is the attribute DW_AT_upper_bound and the crash utility can do it.
<1><58437> DW_TAG_variable
DW_AT_name __per_cpu_offset
DW_AT_decl_file 1 init/main.c
DW_AT_decl_line 363
DW_AT_type <33>
DW_AT_external yes(1)
DW_AT_location DW_OP_addr 0xc03fd400
<1>< 33> DW_TAG_array_type
DW_AT_sibling <49>
DW_AT_type <56>
<2>< 42> DW_TAG_subrange_type
DW_AT_type <49>
DW_AT_upper_bound 31 <--- Here!
I thought get_array_length() should retry to get the array length from
the next if it could not get it. But I prefer your following idea because
it is simple and does not make other effects.
How about using Cliff Wickman's new get_cpus_possible() function
from his LKCD_KERNTYPES patch? Since get_cpus_possible() returns 0
on failure, your fix below should be left in place, but it might be
worth also trying get_cpus_possible() if get_array_length() returns 0?
That sounds good, but I cannot find Cliff Wickman's patch (including
get_cpus_possible() function). Can I see his patch ?
Thanks
Ken'ichi Ohmichi