Thanks a lot Dave. That helps.

Sagar

On Thu, Oct 13, 2016 at 4:03 PM, Dave Anderson <ander...@redhat.com> wrote:
>
>
> ----- Original Message -----
>> On Thu, Oct 13, 2016 at 2:05 PM, Dave Anderson <ander...@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@redhat.com
>> >> https://www.redhat.com/mailman/listinfo/crash-utility
>> >>
>> >
>> > --
>> > Crash-utility mailing list
>> > Crash-utility@redhat.com
>> > https://www.redhat.com/mailman/listinfo/crash-utility
>>
>> --
>> Crash-utility mailing list
>> Crash-utility@redhat.com
>> https://www.redhat.com/mailman/listinfo/crash-utility
>>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Reply via email to