----- "Dave Anderson" <anderson(a)redhat.com&gt; wrote: Ah -- it's becoming clearer now... The evolution of the various xendump formats is the cause for confusion and the issue at hand. In the beginning, the "xm dump-core" facility used its own unique dumpfile format, where the xc_core_header shown above was at the beginning of the dumpfile and served as its primary header. Much later, "xm dump-core" started using an ELF format, where it carried forward 3 of the old xc_core_header fields above into either this ELF note: struct xen_dumpcore_elfnote_header_desc { uint64_t xch_magic; uint64_t xch_nr_vcpus; uint64_t xch_nr_pages; uint64_t xch_page_size; }; or into one of several ELF section headers. The remaining 3 "offset" fields are stored like so: xch_ctxt_offset: in the ".xen_prstatus" ELF section header xch_index_offset: in the ".xen_pfn" or ".xen_p2m" ELF section header depending whether it's fully-virtualized or paravirtualized. xch_pages_offset: in the ".xen_pages" ELF section header The offsets are in the ELF section headers are of "sh_offset" fields of the Elf64_Shdr (or Elf32_Shdr if ELFCLASS32): typedef struct { Elf64_Word sh_name; /* Section name (string tbl index) */ Elf64_Word sh_type; /* Section type */ Elf64_Xword sh_flags; /* Section flags */ Elf64_Addr sh_addr; /* Section virtual addr at execution */ Elf64_Off sh_offset; /* Section file offset */ Elf64_Xword sh_size; /* Section size in bytes */ Elf64_Word sh_link; /* Link to another section */ Elf64_Word sh_info; /* Additional section information */ Elf64_Xword sh_addralign; /* Section alignment */ Elf64_Xword sh_entsize; /* Entry size if section holds table */ } Elf64_Shdr; FWIW, I don't know (or recall) whether ELFCLASS32 is ever used, even with 32-bit xen hosts/guests, because the "sh_offset" in the Elf32_Shdr is of type Elf32_Off, which is 32-bits: /* Type of file offsets. */ typedef uint32_t Elf32_Off; typedef uint64_t Elf64_Off; Anyway, the problem is that the crash utility started using the old xc_core_header data structure when it was the only header. When they started using ELF format dumpfiles, the sh_offset values from the ELF section headers were copied into the old xc_core_header data structure in the crash utility so that the old code base could still be used. But if any of the sh_offset values overflowed into the upper 32-bits, then they would be truncated when the copy was made. In any case, getting back to the crash utility issue, the patch that you proposed cannot be used alone because it will break backwards-compatibility. What could be done is to have the xc_core_verify() initialization code read the dumpfile header into an "original" xc_core_header structure type, verify it as one of the "old-style" dumpfiles, but then store the offsets into your updated xc_core_header structure. Dave The xc_core_header above