6:30 p.m.
Thanks a lot Dave. That helps.
Sagar
On Thu, Oct 13, 2016 at 4:03 PM, Dave Anderson <anderson(a)redhat.com> wrote:
----- Original Message -----
> On Thu, Oct 13, 2016 at 2:05 PM, Dave Anderson <anderson(a)redhat.com> 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(a)redhat.com
> >> https://www.redhat.com/mailman/listinfo/crash-utility
> >>
> >
> > --
> > Crash-utility mailing list
> > Crash-utility(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility