On Fri, 14 Jun 2013 15:40:02 +0530 "Suzuki K. Poulose" <suzuki at in.ibm.com> wrote: > Hi, > > We have been working on enabling 'cross' analysis support for > Crash, where the target and the host differ in endian-ness. > > For e.g, analysing a powerpc dump on an Intel box. > > This would be useful for debugging the dumps captured on an > embedded board (say ppc44x), on a normal desktop PC(Intel based). > > While the patches are being tested for 'Crash' utility we came > across a problem with the analysis of the compressed dump formats(aka > diskdump). There is no information about the endian-ness of the dump > unlike the ELF format. Hence, we need to embed this information during > the makedumpfile processing of vmcores. > > Here are some of the options we thought about : > > 1) Interpret the new_utsname.machine and decode the endian-ness/word > size. > > 2) Extend the signature string to contain information about the > endian-ness / word size. > > e.g, KDUMPB64 - for KDUMP, BigEndian 64bit I had the same issue with a dump identification tool. I ended up with checking whether the fields are "sane" if interpreted in a specific way. You may want to check my code here: http://sourceforge.net/projects/kdumpid/ I agree that this is ugly and a better approach would be to store the information in the header, but then you would not be able to read legacy dumps, which is a major drawback. BTW how far did you get with a cross-platform crash? I did some research on this subject earlier, so maybe I can help you avoid some dead ends..? HTH, Petr Tesarik
