Cross architecture analysis for Crash

Cross architecture analysis for Crash

[Suzuki K. Poulose]

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

Since we don't know the endian-ness yet, we may not be able to use any
of the other fields which are 'int' or 'long' (e.g, status)

I am looking for suggestions or directions on the approach to add this
information.

Thanks
Suzuki




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Cross architecture analysis for Crash

[Petr Tesarik]

On Fri, 14 Jun 2013 15:40:02 +0530
"Suzuki K. Poulose" <suzuki@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

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec