Hello Stefan, > -----Original Message----- > From: Stefan Bader [mailto:stefan.bader at canonical.com] > Sent: Monday, September 17, 2012 2:38 PM > To: Trapp, Norbert > Cc: Atsushi Kumagai; petr at tesarici.cz; kexec at lists.infradead.org > Subject: Re: [PATCHv3 0/9] Support Xen versions up to xen-4.1 > > 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)? > Just to get you on the right track, the struct page_info in the Xen code is meant. Not the one in the makedumpfile code. For example in xen-4.1.3/xen/common/kexec.c: #ifdef __ia64__ VMCOREINFO_OFFSET_SUB(page_info, u.inuse, _domain); #else VMCOREINFO_OFFSET_SUB(page_info, v.inuse, _domain); #endif And the different page_info structures you find in: xen-4.1.3/xen/include/asm-ia64/mm.h xen-4.1.3/xen/include/asm-x86/mm.h And also the structures can be different depending on the Xen version. > > > > 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 PBG 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
