[Crash-utility] Fw: Cross architecture analysis for Crash
I'm taking this thread to the crash-utility mailing list.
I don't know why it didn't get there...
Begin forwarded message:
Date: Wed, 19 Jun 2013 15:33:29 +0200
From: Petr Tesarik <ptesarik(a)suse.cz>
To: kexec(a)lists.infradead.org
Subject: Re: Cross architecture analysis for Crash
On Fri, 14 Jun 2013 15:40:02 +0530
"Suzuki K. Poulose" <suzuki(a)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