Re: [Patch] linux-2.6.22 on i386

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux