Thanks a lot Dave. That helps. Sagar On Thu, Oct 13, 2016 at 4:03 PM, Dave Anderson <anderson@xxxxxxxxxx> wrote: > > > ----- Original Message ----- >> On Thu, Oct 13, 2016 at 2:05 PM, Dave Anderson <anderson@xxxxxxxxxx> wrote: >> > >> > >> > >> > ----- Original Message ----- >> >> Hi, >> >> >> >> I am facing issues with crash 7.1.5 for little endian mips CPU. Crash >> >> is not able to decode the registers. But except registers all other >> >> information is good. I tried to look at the notes section in the core >> >> but doesn't seem anything wrong there. If I trace the vmcore with mips >> >> gdb I can get the correct stack trace and register info. >> >> >> >> crash> i r >> >> The program has no registers now. >> >> gdb: gdb request failed: i r >> >> >> >> crash> bt >> >> PID: 267 TASK: 808f66d0 CPU: 0 COMMAND: "sh" >> >> >> > >> > Hi Sagar, >> > >> > The "i r" gdb command is not supported by the gdb embedded in the crash >> > utility because it is invoked as "gdb vmlinux", and therefore it has no >> > clue about any task or register set in a vmcore. >> >> Thanks Dave. >> I didn't quite get how to poke the registers from crash. Can you give >> me example? > > If the backtrace ended in an exception, then the register set would be > dumped as part of the "bt" output at the point where the exception occurred. > > There is a "help -r" option for dumping the registers that were saved in > the dumpfile header, but looking at the sources, I see that support for > that option for the MIPS architecture was never put in place. > > Looking at the mips.c backtrace code, it looks like "bt" would print nothing > if the sp that it got for the active task from the dumpfile header was invalid. > If you enter "help -D" to dump the dumpfile header contents, you would normally > see the stored registers as part of the NT_PRSTATUS dump of each cpu. But I > see that that feature is also not done for MIPS. > > Lastly, there is a "bt -e" command that searches the stack of the current > task for exception frames (register dumps), but again, that feature was never > implemented for MIPS. > >> >> > I don't know why the "bt" command is not working. MIPS support was wholly >> > written (and supported) by Rabin Vincent. I've modified the subject line >> > to indicate such, as well as cc'ing him directly. >> > >> > Dave >> >> BTW, I have cross compiled gdb for mips and decoding regs and bt and >> rest through that. Not sure whether the gdb in crash detect little >> endian 32 bit mips vmcore. > > It is compiled for 32 bit MIPS, but as I mentioned before, when the > internal embedded gdb module in the crash utility is invoked, it is > as "gdb vmlinux" (i.e., with no "vmcore" argument). It is only used > for accessing the debuginfo data for the kernel source code. It has > absolutely no concept of any tasks, register sets, or anything that > comes from a core file. > > Dave > >> >> Thanks >> Sagar >> >> >> >> >> > >> >> >> >> For the same vmcore, on gdb: >> >> >> >> (gdb) i r >> >> zero at v0 v1 a0 a1 a2 >> >> a3 >> >> R0 00000000 004b376a 00000002 00000001 000024b0 0000000a ffffffff >> >> 00000002 >> >> t0 t1 t2 t3 t4 t5 t6 >> >> t7 >> >> R8 808f1180 00000000 00000001 77ab8000 7fd53050 004b4580 00000000 >> >> 00000000 >> >> s0 s1 s2 s3 s4 s5 s6 >> >> s7 >> >> R16 00000002 808f0b80 808f1180 fffffff2 80d97f10 808f0b8c 00000030 >> >> 00480000 >> >> t8 t9 k0 k1 gp sp s8 >> >> ra >> >> R24 00000002 803b05bc 0000000a 81005890 80d94000 80d97e18 00000020 >> >> 803b05e0 >> >> sr lo hi bad cause pc >> >> 50808000 1100fc03 00000000 00000002 803b05e0 00000000 >> >> >> >> >> >> (gdb) bt >> >> #0 0x00000000 in ?? () >> >> #1 0x803b05e0 in pcieport_sysfs_store (kobj=<optimized out>, >> >> attr=<optimized out>, data=<optimized out>, len=<optimized out>) at >> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/drivers/cisco/pcieport/sysfs.c:59 >> >> #2 0x8021c6bc in kernfs_fop_write (file=<optimized out>, >> >> user_buf=<optimized out>, count=<optimized out>, ppos=0x80d97f10) at >> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/kernfs/file.c:312 >> >> #3 0x801c9020 in __vfs_write (file=0x24b0, p=<optimized out>, >> >> count=<optimized out>, pos=<optimized out>) at >> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:489 >> >> #4 0x801c9eac in vfs_write (file=0x83b187c0, buf=0xa <Address 0xa out >> >> of bounds>, count=<optimized out>, pos=0x80d97f10) at >> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:538 >> >> #5 0x801ca0dc in SYSC_write (count=<optimized out>, buf=<optimized >> >> out>, fd=<optimized out>) at >> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:585 >> >> #6 SyS_write (fd=<optimized out>, buf=<optimized out>, >> >> count=<optimized out>) at >> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/fs/read_write.c:578 >> >> #7 0x8010e1dc in syscall_common () at >> >> /build/sborikar/bodegadev/bodega-dev/mcpu/firmware/linux-4.4/arch/mips/kernel/scall32-o32.S:102 >> >> >> >> Any idea? >> >> >> >> Thanks >> >> Sagar >> >> >> >> -- >> >> 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 >> >> -- >> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
