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

[Dave Anderson]

Hello Rabin,

This looks good -- a really nice addition to the crash utility.  I appreciate
your undertaking the task.

I also now consider you the MIPS maintainer, and hope that I can refer MIPS
specific questions on this list to you.
         
I made two trivial additions, one to fix the "e_machine:" display
here so that it shows "EM_MIPS":
  
  crash> help -n
  ... [ cut ] ...
  
  Elf32_Ehdr:
                  e_ident: \177ELF
        e_ident[EI_CLASS]: 1 (ELFCLASS32)
         e_ident[EI_DATA]: 1 (ELFDATA2LSB)
      e_ident[EI_VERSION]: 1 (EV_CURRENT)
        e_ident[EI_OSABI]: 0 (ELFOSABI_SYSV)
   e_ident[EI_ABIVERSION]: 0
                   e_type: 4 (ET_CORE)
                e_machine: 8 (unsupported)
                e_version: 1 (EV_CURRENT)
  ...

and also added a comma to fix the updated README output.

In the future it might be helpful if the machspec fields were
translated for "help -m" like the other architectures, but I see
that the 32-bit PPC doesn't do it either.

And perhaps it would possible for you to rework configure.c and whatever
else to get it to work for big-endian MIPS as well?  (albeit with the "make target=MIPS")

The patchset is queued for crash-7.1.0:

  https://github.com/crash-utility/crash/commit/04073aacfbf73eb3608a2c7b0bc967db492a815e

I just thought of one thing that's missing.  The crash.spec file needs to have its
ExclusiveArch: line updated for this arch so that it can be built natively using
the src.rpm file.  What should it be, "mipsel", or "mips", or what?

Thanks again,
  Dave

           

----- Original Message -----
> 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
> 
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>