From: Atsushi Kumagai <kumagai-atsushi@xxxxxxxxxxxxxxxxx>
Subject: Re: makedumpfile -g with recent kernels
Date: Tue, 7 Aug 2012 15:24:09 +0900
> Hello HATAYAMA-san,
>
> On Thu, 02 Aug 2012 17:23:05 +0900 (JST)
> HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:
>
>> From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
>> Subject: Re: makedumpfile -g with recent kernels
>> Date: Thu, 2 Aug 2012 15:04:29 +0900
>>
>> > Hello HATAYAMA-san,
>> >
>> > On Thu, 02 Aug 2012 14:47:14 +0900 (JST)
>> > HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:
>> >
>> >> From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
>> >> Subject: Re: makedumpfile -g with recent kernels
>> >> Date: Thu, 2 Aug 2012 14:12:51 +0900
>> >>
>> >> > Hello Stefan,
>> >> >
>> >> > On Mon, 09 Jul 2012 11:17:13 +0200
>> >> > Stefan Bader <stefan.bader at canonical.com> wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> I am not sure whether this really is the preferred way as I heard the required
>> >> >> info now is in vmcore and vmcoreinfo would not be needed anymore. But just to
>> >> >> have it produce some output I noticed that it trips again over some member of
>> >> >> struct page that moved into some anonymous structure/union combo.
>> >> >> There was some code that was quite specific for the page.mapping case (which now
>> >> >> seems to be outside again). I changed the code to be more generic. It did fix my
>> >> >> _count problem and should also handle the mapping case (though I could not test).
>> >> >> So maybe this would be worth adding to the upstream code.
>> >> >>
>> >> >> -Stefan
>> >> >>
>> >> >> Please include me in cc's as I am not subscribed to this ml.
>> >> >
>> >> > Thank you for your nice work!
>> >> >
>> >>
>> >> Hello Kumagai-san,
>> >>
>> >> I want to see a whole part of Stefan's patch. Could you post it on the
>> >> ml?
>> >
>> > This is the Stefan's patch.
>> >
>>
>> Thanks, and this patch helps a lot.
>>
>> BTW, I think we can get rid of DWARF_INFO_GET_MEMBER_OFFSET_1ST_UNION
>> path, too.
>>
>> Thanks.
>> HATAYAMA, Daisuke
>
> At first, I thought so. But DWARF_INFO_GET_MEMBER_OFFSET doesn't work for
> kernel 2.6.16 and 2.6.17 even after applying Stefan's patch.
> Additionally, I couldn't find the Die of page.mapping with dwarfdump in that
> case.
> I don't know why the Die isn't included in some vmlinuxs, anyway, it seems
> that the comment below is true.
>
> 832 /*
> 833 * Some vmlinux(s) don't have debugging information about
> 834 * page.mapping. Then, makedumpfile assumes that there is
> 835 * "mapping" next to "private(unsigned long)" in the first
> 836 * union.
> 837 */
> 838 if (OFFSET(page.mapping) == NOT_FOUND_STRUCTURE) {
> 839 OFFSET(page.mapping) = get_member_offset("page", NULL,
> 840 DWARF_INFO_GET_MEMBER_OFFSET_1ST_UNION);
>
> So DWARF_INFO_GET_MEMBER_OFFSET_1ST_UNION is still necessary for some kernels.
>
Thanks for your explanation. I understand it. I have similar
experience where pt_regs sturcture information is missing for some
kernel debuginfo files.
Thanks.
HATAYAMA, Daisuke
