Re: Can't debug core files with GDB

[ashley jones <ashley_jones_2000@xxxxxxxxx>]

   check out  "google coredumper"  it is an opensource coredump utlity.

 

Regards,

A'Jones.

Tony Lin <lin.tony@xxxxxxxxx> wrote:

I've pretty much concluded the gdb is not at fault. Loading a coredump
generated by another mips-linux system, it was able to read the
registers correctly and lookup the program counter.

So the problem now is my 32-bit mips-linux is generating core files in
a different format than what gdb expects. I've been digging into
fs/exec.c and fs/binfmt_elf.c without much success. Are there
documents describing the expected coredump header format?

I'm not really familiar with the register terminology (fpu? xfpregs?)
so am having some trouble figuring out where linux write the program
counter into the core dump.

Thanks for all your help,
- Tony


On 5/24/06, ashley jones wrote:
>
> hi,
> where are you running your GDB ? on i386 ? then i guess you shouldnt
> specify --host=mips-linux. just run .configure script and specify only
> target as mips-linux.
>
> Regards,
> A'Jones.
>
>
>
> Tony Lin wrote:
>
> Objdump didn't yield any useful information, perhaps I didn't set the
> flags correctly to show all the private registers.
>
> You may be right about the kernel generated core file though. I
> checked the registerd in gdb, everything looks good except the program
> counter was zero. I then modified the mips kernel to spit out the
> registers when doing the coredump. A valid pc (0x4008c0) was there
> when doing fs/exec.c:do_coredump()
>
> printks from do_coredump()
> -----------
> bash-2.05a# killall -SIGSEGV nebtest
> 1:<6>
>
> printing contents of pt_regs *regs
> 1:<6>cp0_status 0xdc13
> 1:<6>lo 0x0
> 1:<6>hi 0x0
> 1:<6>cp0_badvaddr 0x803fbda0
> 1:<6>cp0_cause 0x10801000
> 1:<6>cp0_epc 0x4008c0
>
>
> Calling 'info registers' in gdb coredump
> ----------------------
> Reading symbols from /lib/ld.so.1...done.
> Loaded symbols for /lib/ld.so.1
> #0 0x00000000 in ?? ()
> (gdb) info registers
> zero at v0 v1 a0 a1 a2 a3
> R0 00000000 1000dc00 0000000f 00000000 0000000f 2aac1000 0000000f 00000000
> t0 t1 t2 t3 t4 t5 t6 t7
> R8 00000000 00000001 00000003 49276d20 68697320 00000000 00000000 7468656e
> s0 s1 s2 s3 s4 s5 s6 s7
> R16 2ab00230 7fff7e64 2ad09f50 004008d0 00000001 004007dc 00000000 1001f328
> t8 t9 k0 k1 gp sp s8 ra
> R24 00000003 00000000 fbad2a84 00000000 10008040 7fff7de0 7fff7de0 00400898
> sr lo hi bad cause pc
> 10801000 0000dc13 00000000 803fbda0 004008c0 00000000
> fsr fir
> 00000000 00000000
> (gdb)
>
> (gdb) x/32 0x4008c0
> 0x4008c0 : 0x1000ffff 0x00000000 0x00000000
>
> 0x00000000
> 0x4008d0 <__libc_csu_init>: 0x3c1c0fc0 0x279c7770
> 0x0399e021 0x27bdffd8
> 0x4008e0 <__libc_csu_init+16>: 0xafbf0020 0xafb1001c
> 0xafb00018 0xafbc0010
> 0x4008f0 <__libc_csu_init+32>: 0x8f998054 0x00000000
> 0x0320f809 0x00000000
> 0x400900 <__libc_csu_init+48>: 0x8fbc0010 0x8f838034
> 0x8f828040 0x00431023
>
>
>
> The 0x4008c0 address doesn't look half bad, pointing within main(). So
> it looks like the mips kernel had all the right registers values but
> just didn't format it correctly in the core dump? It wrote the pc into
> cause, cause into sr, and cp0_status into lo.
>
>
> Thanks much,
> - Tony
>
> On 5/17/06, Daniel Jacobowitz wrote:
> > Check the contents of the core file with objdump? I recall seeing at
> > least one recent MIPS kernel which failed to save registers. Take a
> > look at the .reg section.
> >
> > --
> > Daniel Jacobowitz
> > CodeSourcery
> >
>
>
>
>
>
> ________________________________
> How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates.
>
>

---

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.