[Crash-utility] [PATCH 0/4] MIPS support

[Rabin Vincent]

On Mon, Jan 12, 2015 at 11:00:08AM -0500, Dave Anderson wrote:
> I don't know what the real-world usage is with respect to little-endian
> vs. big-endian 32-bit MIPS, but you got here first.  And in the
> future, it should be simple enough to support big-endian MIPS as
> well, i.e., in the same manner that both little- and big-endian PPC64
> are supported.

I attempted to have a quick look at big-endian while making the patch
(it's easy to emulate big-endian MIPS too on QEMU), and if I understand
correctly from the PPC handling, the host endianness needs to match the
target endianness.  So that means we can't analyze big-endian MIPS dumps
on x86/x86-64 hosts, right?

The MIPS systems which I personally plan to use this for are
little-endian, and the analysis will be done on x86-64 hosts.

> Running cscope from the gdb-7.6 subdirectory on down shows only
> this single reference to convert:
> 
>   sim/mips/sim-main.h Convert  774 #define Convert(rm,op,from,to) convert (SIM_ARGS, rm, op, from, to)
> 
> But it doesn't show any callers to Convert() or convert().  So
> it appears to exist as a non-static function in "sim/mips/cp1.c"
> that nobody calls?  In any case, please make the convert() name 
> change down in the gdb-7.6/sim/mips code, and update gdb-7.6.patch
> accordingly.

Done.  Convert() is used in the mips.igen file in the same directory,
which appears to be used to generate C code and compile it as part of
the build process.

> Also in defs.h, please put the task_struct_thread_reg29 and
> task_struct_thread_reg31 offsets at the end of the offset_table
> structure.  Again, new entries to that structure should always
> be appended to the structure so that it won't break the usage 
> of OFFSET() by pre-existing extension modules.  Also, you should
> add their offset value displays to dump_offset_table() for use 
> by "help -o", and in that function, you can display it next to 
> the other task_struct_thread_xxx offsets.

Done.

> On another note, there should be an understandable and clean 
> protection mechanism against running a target=MIPS binary on a 
> live host system.  So when attempting to run a target=ARM crash
> binary on an x86/x86_64 host, it fails like so:
> 
>   $ sudo ./crash
>   crash: compiled for the ARM architecture
>   
> With your target=MIPS binary, it shows this confusing error message:
>   
>   crash: cannot resolve "cpu_data"
>   
> It's a small check that can be put at the beginning of mips_init().
> I presume that you used ppc.c as a template, so if you'd like, you
> can add the same fix there as well.

ppc.c doesn't have that check, but I've added it to mips.c based on
what's in arm.c.

> Lastly (at least at this point), can you update the README[] strings array
> in help.c to show that MIPS is a supported architecture, and that it can
> be build as a "target=" binary?

Done.

> Oh, and thanks very much for the sample vmcores.  I'll keep them around for future
> testing.  BTW, the System.map file is completely unnecessary -- is there a reason
> you included it?

Not really.  I never used it but thought "just in case" while zipping up
the dumps + vmlinux.

Rabin