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