From: Stefan Bader <stefan.bader@canonical.com>
To: "Trapp, Norbert" <norbert.trapp@ts.fujitsu.com>
Cc: "petr@tesarici.cz" <petr@tesarici.cz>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Subject: Re: [PATCHv3 0/9] Support Xen versions up to xen-4.1
Date: Mon, 17 Sep 2012 14:38:21 +0200 [thread overview]
Message-ID: <505719BD.6080608@canonical.com> (raw)
In-Reply-To: <0E9227E8EFCFF54EA493F6C0399C015D39C0F0F687@ABGEX70E.FSC.NET>
[-- Attachment #1.1: Type: text/plain, Size: 3615 bytes --]
On 12.09.2012 16:39, Trapp, Norbert wrote:
> Hello Atsushi, Petr, Stefan et al.,
>
Hi Norbert,
> When applying the makedumpfile Xen4 patches to the makedumpfile 1.5.0
> version and using it for a crash file to save just the dom0 and xen pages
> it again worked splendid in that makedumpfile was much faster than without
> the Xen4 patches. Alas I had to remove the OFFSET_IN_UNION_INIT(page._domain,
> "page_info", "domain") call because OFFSET_IN_UNION_INIT was no longer present.
> It didn't matter much because the call is only needed for makedumpfile -g or when
> using the /boot/xen-syms file. In the current 1.5.0 makedumpfile.c version you
> see
>
> OFFSET_INIT(page_info._domain, "page_info", "u").
>
> The Xen4 patch modified this because the _domain structure member is in different
> unions for different version (x86, ia64) and may also not be the first entry in
> the union depending on the Xen version.
>
> OFFSET_IN_UNION_INIT(page_info._domain, "page_info", "_domain");
>
> As an experiment I tried to use
>
> OFFSET_INIT(page_info._domain, "page_info", "domain")
Just to make sure and since I am a bit lazy: with the Xen patch the page_info
structure has a member (somewhere) named domain? (or _domain)?
>
> with makedumpfile 1.5.0. To get the correct offset I had to
> modify the dwarf_info.c code:
>
> --- ../makedumpfile-1.5.0/dwarf_info.c 2012-09-06 07:30:23.000000000 +0200
> +++ dwarf_info.c 2012-09-12 15:49:23.000000000 +0200
> @@ -449,8 +449,8 @@
> static int
> is_anonymous_container(Dwarf_Die *die)
> {
> - if (dwarf_diename(die))
> - return FALSE;
> + //if (dwarf_diename(die))
> + // return FALSE;
> if (dwarf_tag(die) == DW_TAG_structure_type)
> return TRUE;
> if (dwarf_info.cmd != DWARF_INFO_GET_MEMBER_OFFSET_1ST_UNION
> @@ -495,7 +495,7 @@
> * Descend into anonymous members and search for member
> * there.
> */
> - if (!name) {
> + if ((!name) || (strcmp(name, dwarf_info.member_name) != 0)) {
> if (!get_die_type(walker, &die_type))
> continue;
> if (is_anonymous_container(&die_type))
>
>
> This is not a patch but just a description of what I modified for a test.
> The underlying question is why only the anonymous unions are used and not the
> ones with a name.
I made the patch because one element in some anonymous structure/union combo was
not found in newer kernels and the previous exceptions for such a thing were
hard coded. But as far as the dwarf info I was looking at the named
structures/unions were handled and I did not want to modify that case without a
way to test.
-Stefan
>
> With kind regards
>
> Norbert
>
> Norbert Trapp
> PDG ES&S SWE OS 6
>
> FUJITSU
> Fujitsu Technology Solutions GmbH
> Domagkstraße 28, D-80807 München, Germany
> E-mail: Norbert.Trapp at ts.fujitsu.com
> Web: ts.fujitsu.com
> Company details: ts.fujitsu.com/imprint
>
>> -----Original Message-----
>> From: Atsushi Kumagai [mailto:kumagai-atsushi@mxc.nes.nec.co.jp]
>> Sent: Monday, September 03, 2012 7:01 AM
>> To: Trapp, Norbert; petr@tesarici.cz
>> Cc: kexec@lists.infradead.org
>> Subject: Re: [PATCHv3 0/9] Support Xen versions up to xen-4.1
>>
> ...
>>
>> Thank you for your report, that's good.
>> So, I'll review these patches for makedumpfile-1.5.1.
>>
>>
>> Thanks
>> Atsushi Kumagai
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-09-17 12:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-24 15:41 [PATCHv3 0/9] Support Xen versions up to xen-4.1 Petr Tesařík
2012-08-31 15:05 ` Trapp, Norbert
2012-09-03 5:01 ` Atsushi Kumagai
2012-09-12 14:39 ` Trapp, Norbert
2012-09-17 12:38 ` Stefan Bader [this message]
2012-09-17 16:52 ` Trapp, Norbert
2012-09-18 6:38 ` Atsushi Kumagai
-- strict thread matches above, loose matches on Subject: below --
2012-08-24 15:46 Petr Tesarik
2012-08-27 7:20 ` Atsushi Kumagai
2012-08-27 16:19 ` Trapp, Norbert
2012-08-27 16:41 ` Petr Tesarik
2012-08-28 10:02 ` Petr Tesarik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=505719BD.6080608@canonical.com \
--to=stefan.bader@canonical.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
--cc=norbert.trapp@ts.fujitsu.com \
--cc=petr@tesarici.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox