Hi Dave, 2007/07/25 10:28:04 -0400, Dave Anderson <anderson@xxxxxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
