Can't debug core files with GDB

Can't debug core files with GDB

[Tony Lin]

Hi there,

I have a gdb-6.4 that I cross-compiled for mips-linux. Along with my
test program, I can use gdb to walk the code execution just fine, but
is unable to read core dumps. Maybe you guys can spot if I did
something wrong.

Machine used to compile gdb:
---
i386-linux, using cross-compiled mips toolchain (gcc 3.4.3, glibc 2.3.2)
target kernel is mips-linux-2.6.6

gdb was configured with:
---
export CC=mipsisa32-linux-gcc
export AR=mipsisa32-linux-ar
../gdb/configure --build=i386-linux --host=mips-linux
--target=mips-linux --disable-sim

resulting gdb file:
gdb: ELF 32-bit MSB executable, MIPS, version 1 (SYSV), for GNU/Linux
2.4.3, dynamically linked (uses shared libs), not stripped


When I force a core file and try to debug it, I get empty values:

> ./gdb ./nebtest ./core.524.nebtest

GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "mips-linux"...Using host libthread_db
library "/lib/libthread_db.so.1".

Core was generated by `./nebtest'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
#0  0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x00000000 in ?? ()







Any idea what this may be? It's strange because if I just do 'gdb
nebtest' I can step through the program just fine. It's reading core
files that fail.

Thanks much!

Re: Can't debug core files with GDB

[Daniel Jacobowitz]

On Tue, May 16, 2006 at 05:02:35PM -0700, Tony Lin wrote:
> When I force a core file and try to debug it, I get empty values:
> 
> >./gdb ./nebtest ./core.524.nebtest
> 
> GNU gdb 6.4
> Copyright 2005 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "mips-linux"...Using host libthread_db
> library "/lib/libthread_db.so.1".
> 
> Core was generated by `./nebtest'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libgcc_s.so.1...done.
> Loaded symbols for /lib/libgcc_s.so.1
> Reading symbols from /lib/libc.so.6...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/ld.so.1...done.
> Loaded symbols for /lib/ld.so.1
> #0  0x00000000 in ?? ()
> (gdb) bt
> #0  0x00000000 in ?? ()
> #1  0x00000000 in ?? ()

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

Re: Can't debug core files with GDB

[Tony Lin]

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 <main+228>:    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 <dan@debian.org> 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
>

Re: Can't debug core files with GDB

[Daniel Jacobowitz]

On Wed, May 17, 2006 at 11:39:47AM -0700, Tony Lin wrote:
> 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.

Then either the kernel or GDB is confused about the layout.  You'll
have to work out which one has gotten wrong.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can't debug core files with GDB

[ashley jones]

[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]

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@gmail.com> 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.

[-- Attachment #2: Type: text/html, Size: 3310 bytes --]

Re: Can't debug core files with GDB

[Tony Lin]

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@yahoo.com> 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@gmail.com> 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.
>
>

Re: Can't debug core files with GDB

[ashley jones]

[-- Attachment #1: Type: text/plain, Size: 3720 bytes --]

   check out  "google coredumper"  it is an opensource coredump utlity. 
   
  Regards,
  A'Jones.

Tony Lin <lin.tony@gmail.com> 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&cent;/min.

[-- Attachment #2: Type: text/html, Size: 4825 bytes --]

Re: Can't debug core files with GDB

[Daniel Jacobowitz]

On Wed, May 24, 2006 at 06:44:26PM -0700, Tony Lin 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?

No.  But...

> 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.

Take a look at asm-mips/elf.h and IIRC arch/mips/kernel/process.c.  Or,
trace the macros through binfmt_elf.c, where it creates NOTE sections.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can't debug core files with GDB

[Tony Lin]

Hmm... It looks like the output format changed between linux 2.4 ->
2.6. In 2.4's include/asm-mips/ptrace.h, we have:
struct pt_regs {
       /* Pad bytes for argument save space on the stack. */
       unsigned long pad0[6];

       /* Saved main processor registers. */
       unsigned long regs[32];

       /* Other saved registers. */
       unsigned long lo;
       unsigned long hi;

       /*
        * saved cp0 registers
        */
       unsigned long cp0_epc;
       unsigned long cp0_badvaddr;
       unsigned long cp0_status;
       unsigned long cp0_cause;

Then in 2.6, it changes to:
struct pt_regs {
#ifdef CONFIG_MIPS32
       /* Pad bytes for argument save space on the stack. */
       unsigned long pad0[6];
#endif

       /* Saved main processor registers. */
       unsigned long regs[32];

       /* Saved special registers. */
       unsigned long cp0_status;
       unsigned long lo;
       unsigned long hi;
       unsigned long cp0_badvaddr;
       unsigned long cp0_cause;
       unsigned long cp0_epc;
};

Notice how the offsets has changed, no idea why this was done. I
loaded the core file in the hex dump, and sure enough it is dumped
with this new ordering.

I guess gdb is still trying to decode using the old pt_regs format. Is
it correct to modify gdb to use this new format? Or modify linux to
output using the old format?

Thanks much,
- Tony

On 5/25/06, Daniel Jacobowitz <dan@debian.org> wrote:
> On Wed, May 24, 2006 at 06:44:26PM -0700, Tony Lin 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?
>
> No.  But...
>
> > 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.
>
> Take a look at asm-mips/elf.h and IIRC arch/mips/kernel/process.c.  Or,
> trace the macros through binfmt_elf.c, where it creates NOTE sections.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: Can't debug core files with GDB

[Daniel Jacobowitz]

On Thu, May 25, 2006 at 05:50:56PM -0700, Tony Lin wrote:

[2.4]

>       /*
>        * saved cp0 registers
>        */
>       unsigned long cp0_epc;
>       unsigned long cp0_badvaddr;
>       unsigned long cp0_status;
>       unsigned long cp0_cause;

[2.6]

>       /* Saved special registers. */
>       unsigned long cp0_status;
>       unsigned long lo;
>       unsigned long hi;
>       unsigned long cp0_badvaddr;
>       unsigned long cp0_cause;
>       unsigned long cp0_epc;

> Notice how the offsets has changed, no idea why this was done. I
> loaded the core file in the hex dump, and sure enough it is dumped
> with this new ordering.
> 
> I guess gdb is still trying to decode using the old pt_regs format. Is
> it correct to modify gdb to use this new format? Or modify linux to
> output using the old format?

Ralf, do you remember why this changed?  I don't.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can't debug core files with GDB

[Johannes Stezenbach]

On Thu, May 25, 2006, Daniel Jacobowitz wrote:
> On Thu, May 25, 2006 at 05:50:56PM -0700, Tony Lin wrote:
> 
> [2.4]
> 
> >       /*
> >        * saved cp0 registers
> >        */
> >       unsigned long cp0_epc;
> >       unsigned long cp0_badvaddr;
> >       unsigned long cp0_status;
> >       unsigned long cp0_cause;
> 
> [2.6]
> 
> >       /* Saved special registers. */
> >       unsigned long cp0_status;
> >       unsigned long lo;
> >       unsigned long hi;
> >       unsigned long cp0_badvaddr;
> >       unsigned long cp0_cause;
> >       unsigned long cp0_epc;
> 
> > Notice how the offsets has changed, no idea why this was done. I
> > loaded the core file in the hex dump, and sure enough it is dumped
> > with this new ordering.
> > 
> > I guess gdb is still trying to decode using the old pt_regs format. Is
> > it correct to modify gdb to use this new format? Or modify linux to
> > output using the old format?

BTW, buildroot has a 400-mips-coredump.patch-2.4.23-29 patch.
http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/toolchain/gdb/

However, I've built a toolchain using gcc-3.4.4, uClibc 0.9.27-cvs,
gdb 6.3, kernel 2.6.13, and I had to build without the
buildroot 400-mips-coredump.patch-2.4.23-29 patch. Without
it my gdb can read coredumps without problems.


Johannes

Re: Can't debug core files with GDB

[Tony Lin]

Finally found the place in gdb to change the register values to read
the coredump correctly. However I have a nagging feeling that I may
not have configured gdb correctly , and my fix may not be the right
one. But oh wells, at least it works!

cross-compiled on: i386-linux
configured gdb using: ../gdb/configure --target=mips-linux
gdb-6.4, kernel 2.6.6-rc3, gcc-3.4.3

*** mips-linux-tdep.c   2006-05-26 17:14:00.577339000 -0700
--- mips-linux.tdep.c~  2006-05-26 17:15:53.723372000 -0700
***************
*** 54,65 ****
--- 54,76 ----
+
+ /* NEW 2.6 style */
+ #define EF_CP0_STATUS         38
+ #define EF_LO                 39
+ #define EF_HI                 40
+ #define EF_CP0_BADVADDR               41
+ #define EF_CP0_CAUSE          42
+ #define EF_CP0_EPC            43
+
+ /* OLD 2.4 style
  #define EF_LO                 38
  #define EF_HI                 39
  #define EF_CP0_EPC            40
  #define EF_CP0_BADVADDR               41
  #define EF_CP0_STATUS         42
  #define EF_CP0_CAUSE          43
+ */

Is it possible that since I cross-compiled gdb on an i386, it used the
local gcc/libc to compile and didn't have the right registers header
file? I know during configuration it was complaining that it didn't
find greg_t definitions etc. I suppose this why you guys can compile
it correctly on the native mips-linux while I have issues
cross-compiling on i386-linux.

Thanks for all your help!
- Tony

Re: Can't debug core files with GDB

[Daniel Jacobowitz]

On Fri, May 26, 2006 at 05:21:44PM -0700, Tony Lin wrote:
> Is it possible that since I cross-compiled gdb on an i386, it used the
> local gcc/libc to compile and didn't have the right registers header
> file? I know during configuration it was complaining that it didn't
> find greg_t definitions etc. I suppose this why you guys can compile
> it correctly on the native mips-linux while I have issues
> cross-compiling on i386-linux.

No.  I build both cross and native debuggers, of course.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can't debug core files with GDB

[Johannes Stezenbach]

On Fri, May 26, 2006, Tony Lin wrote:
> Finally found the place in gdb to change the register values to read
> the coredump correctly. However I have a nagging feeling that I may
> not have configured gdb correctly , and my fix may not be the right
> one. But oh wells, at least it works!
> 
> cross-compiled on: i386-linux
> configured gdb using: ../gdb/configure --target=mips-linux
> gdb-6.4, kernel 2.6.6-rc3, gcc-3.4.3
> 
> *** mips-linux-tdep.c   2006-05-26 17:14:00.577339000 -0700
> --- mips-linux.tdep.c~  2006-05-26 17:15:53.723372000 -0700
> ***************
> *** 54,65 ****
> --- 54,76 ----
> +
> + /* NEW 2.6 style */
> + #define EF_CP0_STATUS         38
> + #define EF_LO                 39
> + #define EF_HI                 40
> + #define EF_CP0_BADVADDR               41
> + #define EF_CP0_CAUSE          42
> + #define EF_CP0_EPC            43
> +
> + /* OLD 2.4 style
>  #define EF_LO                 38
>  #define EF_HI                 39
>  #define EF_CP0_EPC            40
>  #define EF_CP0_BADVADDR               41
>  #define EF_CP0_STATUS         42
>  #define EF_CP0_CAUSE          43
> + */
> 
> Is it possible that since I cross-compiled gdb on an i386, it used the
> local gcc/libc to compile and didn't have the right registers header
> file? I know during configuration it was complaining that it didn't
> find greg_t definitions etc. I suppose this why you guys can compile
> it correctly on the native mips-linux while I have issues
> cross-compiling on i386-linux.

Maybe the change to the coredump format was reverted in later
2.6 kernels. If so, Ralf might remember.

Johannes