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 <ashley_jones_2000@xxxxxxxxx> 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 <lin.tony@xxxxxxxxx> 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.
