On Tue, Mar 05, 2013 at 10:32:26AM -0500, Dave Anderson wrote: > > > With respect to this long-running thread: > > Question for ARM developers/users w/respect to makedumpfile > https://www.redhat.com/archives/crash-utility/2013-January/msg00049.html > > and the kludge/patch that went into crash-6.1.3: > > - Workaround for the "crash --osrelease dumpfile" option to be able > to work with malformed ARM compressed kdump headers. ARM compressed > kdumps that indicate header version 3 may contain a malformed > kdump_sub_header structure with offset_vmcoreinfo and size_vmcoreinfo > fields offset by 4 bytes, and the actual vmcoreinfo data is not > preceded by its ELF note header and its "VMCOREINFO" string. This > workaround finds the vmcoreinfo data and patches the stored header's > offset_vmcoreinfo and size_vmcoreinfo values. Without the patch, the > "--osrelease dumpfile" command line option fails with the message > "crash: compressed kdump: cannot lseek dump vmcoreinfo", followed by > "unknown". > (anderson@xxxxxxxxxx) > > Luc Chouinard has come to the rescue and figured out what was going on. Thanks a lot Luc! > It is not a matter of a "malformed" ARM compressed kdump header, but rather > a result of using a 32-bit x86 crash binary created with "make target=ARM" > to analyze ARM compressed kdumps. > > The ARM guys on the list can confirm this, but Luc debugged this issue > with a natively-built crash utility, and determined: > > Seems like the off_t members of the kdump_sub_header struct are being > aligned on 8 byte boundaries. Which would explain the problem you are > pointing out. This can be a normal compiler behavior for the arm processor, > which will generate exceptions for unaligned memory accesses. This is > something we had to chase down and fix for some of our cross platform > code base (i386 and arm). The Arm experts may have to confirm, but I'd > think that all 'long long' members of structs may cause problem when > cross interpreted by a ARM crash. > > Now AFAICT, I believe that the only "cross interpreted" items that would > come into play would be the kdump_sub_header: > > struct kdump_sub_header { > unsigned long phys_base; > int dump_level; /* header_version 1 and later */ > int split; /* header_version 2 and later */ > unsigned long start_pfn; /* header_version 2 and later */ > unsigned long end_pfn; /* header_version 2 and later */ > off_t offset_vmcoreinfo; /* header_version 3 and later */ > unsigned long size_vmcoreinfo; /* header_version 3 and later */ > off_t offset_note; /* header_version 4 and later */ > unsigned long size_note; /* header_version 4 and later */ > off_t offset_eraseinfo; /* header_version 5 and later */ > unsigned long size_eraseinfo; /* header_version 5 and later */ > }; > > The header is originally created on the crashing ARM host, and written > by an ARM makedumpfile binary into the dumpfile header. But when crash > is build on an x86/x86_64 host with "make target=ARM", but resultant > binary is a 32-bit x86 binary: > > $ make target=ARM > ... > $ file crash > crash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x0459d34779357928839cd4d05f04517a441dc555, not stripped > > And when compiled as an x86 binary, the structure's offsets would be: > > struct kdump_sub_header { > [0] unsigned long phys_base; > [4] int dump_level; /* header_version 1 and later */ > [8] int split; /* header_version 2 and later */ > [12] unsigned long start_pfn; /* header_version 2 and later */ > [16] unsigned long end_pfn; /* header_version 2 and later */ > [20] off_t offset_vmcoreinfo; /* header_version 3 and later */ > [28] unsigned long size_vmcoreinfo; /* header_version 3 and later */ > [32] off_t offset_note; /* header_version 4 and later */ > [40] unsigned long size_note; /* header_version 4 and later */ > [44] off_t offset_eraseinfo; /* header_version 5 and later */ > [52] unsigned long size_eraseinfo; /* header_version 5 and later */ > }; > > But when compiled on an ARM processor, each 64-bit "off_t" would be pushed > up to an 8-byte boundary: > > struct kdump_sub_header { > [0] unsigned long phys_base; > [4] int dump_level; /* header_version 1 and later */ > [8] int split; /* header_version 2 and later */ > [12] unsigned long start_pfn; /* header_version 2 and later */ > [16] unsigned long end_pfn; /* header_version 2 and later */ > [24] off_t offset_vmcoreinfo; /* header_version 3 and later */ > [32] unsigned long size_vmcoreinfo; /* header_version 3 and later */ > [40] off_t offset_note; /* header_version 4 and later */ > [48] unsigned long size_note; /* header_version 4 and later */ > [56] off_t offset_eraseinfo; /* header_version 5 and later */ > [62] unsigned long size_eraseinfo; /* header_version 5 and later */ > }; It just occured to me that we compile makedumpfile for ARM with following flags: -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE and looks like crash doesn't have such flags set. Do you think setting those might help here? -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
