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