Re: gdb backtrace with core files

Re: gdb backtrace with core files

[Brian Kuschak]

Which kernel version are you using?  Are you getting a
complete backtrace with the x86-hosted gdb?

Thanks,
Brian

--- Greg Weeks <greg.weeks@timesys.com> wrote:
> Brian Kuschak wrote:
> 
> >Greg,
> >
> >Is your GDB hosted on MIPS or another machine?  Are
> >those patches freely available?  If so, can you
> >  
> >
> OK, I checked.
> 
> Most of what's in our patches should be in gdb HEAD.
> We're currently at 
> 6.2.1 and don't want to take the time to move to
> head. If you're 
> interested and no one objects I can post them to the
> mips list. There 
> are 37 patches totaling 285K. Not all are mips
> related and gdb isn't 
> totally working for me yet.
> 
> Greg Weeks
> 


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

Re: gdb backtrace with core files

[Greg Weeks]

Brian Kuschak wrote:

>Which kernel version are you using?  Are you getting a
>complete backtrace with the x86-hosted gdb?
>
>  
>
2.6.12-rcwhatever from the malta linux tree. I also have a 2.6.11.6 tree 
I'm playing with. I've not tried the x86 hosted gdb yet. It wouldn't 
surprise me if that one didn't work. The Timesys gdb has historically 
had problems with core dumps on the x86 hosted gdb.

Greg Weeks

Re: gdb backtrace with core files

[Brian Kuschak]

> > OK, tried again with version (GNU gdb
> > 6.3.50.20050407-cvs.)  Same result.
> > 
> > I'm running gdb on x86 host, debugging a binary
> for a
> > MIPS target.  I configured gdb as
> > ./configure --target mipsel-linux-gnu
> --enable-shared
> > --enable-threads 
> > 
> > Perhaps gdb isn't getting the right kernel headers
> > when built?  I added the configure options
> > --includedir and --oldincludedir to point to my
> > linux-mips kernel tree, but that didn't help
> either.  
> 
> It does not use the kernel headers to work out the
> layout.  Are you
> using a current kernel?  I tested core dump support
> only a couple weeks
> ago.

I'm using a 2.4.25 vendor-patched kernel from
Broadcom.  I can poke around and compare the
core-dumping code to the latest mips-linux tree to see
if anything is different.

Brian
 


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

Re: gdb backtrace with core files

[Greg Weeks]

Brian Kuschak wrote:

>Greg,
>
>Is your GDB hosted on MIPS or another machine?  Are
>those patches freely available?  If so, can you
>  
>
OK, I checked.

Most of what's in our patches should be in gdb HEAD. We're currently at 
6.2.1 and don't want to take the time to move to head. If you're 
interested and no one objects I can post them to the mips list. There 
are 37 patches totaling 285K. Not all are mips related and gdb isn't 
totally working for me yet.

Greg Weeks

Re: gdb backtrace with core files

[Greg Weeks]

Brian Kuschak wrote:

>Greg,
>
>Is your GDB hosted on MIPS or another machine?  Are
>those patches freely available?  If so, can you
>provide a link?  Google seems to find mostly kgdb
>patches - are these what you used?
>
>  
>
I have an i386 hosted gdb and a mips native gdb. The backtrace test I 
did was for the native gdb.

I'm not sure which patches are available. I'll check. I'm in the process 
of working up our first BSP with this toolchain.

Greg Weeks

Re: gdb backtrace with core files

[Brian Kuschak]

Greg,

Is your GDB hosted on MIPS or another machine?  Are
those patches freely available?  If so, can you
provide a link?  Google seems to find mostly kgdb
patches - are these what you used?

Brian

--- Greg Weeks <greg.weeks@timesys.com> wrote:
> Brian Kuschak wrote:
> 
> >Is anyone succesfully using gdb for mipsel to debug
> >core dumps?  If so, can you share your secrets for
> >success?  I tried various recent versions (6.3,
> >6.1.1), but backtrace never works right, even
> though
> >the stack pointer appears to be valid.  gdb-5.3
> >partially works, but not completely.  
> >
> >Forcing gdb to use a specific stack pointer and PC
> >(frame <sp> <pc>) doesn't seem to help either.  
> >
> >Using linux 2.4.25 and gcc 3.3.3.
> >
> >  
> >
> It appears to work for me. My gdb has a ton of
> patches from Amit Kale 
> though. The kernel is the latest malta with a couple
> of patches that 
> shouldn't affect gdb.
> 
> -bash-2.05b# gdb
> GNU gdb TimeSys Linux (6.2.1-1rh)
> Copyright 2004 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 "mipsel-linux".
> (gdb) file gdb_core_tester
> Reading symbols from 
>
/root/TestWare/TTS_2.4.2/command/gdb_man/gdb_core_tester...done.
> Using host libthread_db library
> "/lib/libthread_db.so.1".
> (gdb) core-file core.2045
> Core was generated by `./gdb_core_tester'.
> Program terminated with signal 11, Segmentation
> fault.
> Reading symbols from /usr/lib/libgcc_s.so.1...done.
> Loaded symbols for /usr/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  0x00400f48 in add_node (rootptr=0x1000105c,
> nodeval=193)
>     at create_core.c:75
> 75              if(node_ptr->value.value >= nodeval)
> {
> (gdb) bt
> #0  0x00400f48 in add_node (rootptr=0x1000105c,
> nodeval=193)
>     at create_core.c:75
> #1  0x00400fcc in add_node (rootptr=0x10001048,
> nodeval=193)
>     at create_core.c:81
> #2  0x00400f74 in add_node (rootptr=0x10000140,
> nodeval=193)
>     at create_core.c:76
> #3  0x00400df8 in create_tree (rootptr=0x10000140)
> at create_core.c:38
> #4  0x00400b4c in main (argc=1, argv=0x7f931b44) at
> main.c:25
> 
> Greg Weeks
> 


		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

Re: gdb backtrace with core files

[Daniel Jacobowitz]

On Thu, Apr 07, 2005 at 11:23:10AM -0700, Brian Kuschak wrote:
> No luck with latest CVS version (GNU gdb
> 6.3.0.20050407-cvs):

That looks like a 6.3 branch snapshot; I meant HEAD.

> (gdb) t
> [Current thread is 1 (process 362)]
> (gdb) bt
> #0  0x00000658 in ?? ()
> #1  0x00000658 in ?? ()
> (gdb) info registers
>           zero       at       v0       v1       a0    
>   a1       a2       a3
>  R0   00000000 2ab01970 00000000 00000338 00000000
> 00000000 00000000 00000db0
>             t0       t1       t2       t3       t4    
>   t5       t6       t7
>  R8   0dafd6e5 00000001 2abccfd4 2abc8034 00000001
> 2aac2948 00000001 2abe0ce4
>             s0       s1       s2       s3       s4    
>   s5       s6       s7
>  R16  00400f70 7fff7e74 00400ed0 00000001 00400c70
> 00000000 10010f80 00000000
>             t8       t9       k0       k1       gp    
>   sp       s8       ra
>  R24  00000263 2ad2c788 2af318b5 00000000 2af8dab0
> 7fff7bf0 7fff7bf0 2abe0ce4
>             sr       lo       hi      bad    cause    
>   pc
>       00800008 00108413 0001b4e9 800649b8 2ad2c7c8
> 00000658
>            fsr      fir
>       00000000 00000000
> (gdb)

Did your application really jump to 0x658 before it crashed?  Did it
really get a value in the shared library / mmap region into the cause
register?  Looks like your GDB and kernel don't agree on what a core
file looks like.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdb backtrace with core files

[Brian Kuschak]

No luck with latest CVS version (GNU gdb
6.3.0.20050407-cvs):

(gdb) bt
warning: GDB can't find the start of the function at
0x658.
 
    GDB is unable to find the start of the function at
0x658
and thus can't determine the size of that function's
stack frame.
This means that GDB may be unable to access that stack
frame, or
the frames below it.
    This problem is most likely caused by an invalid
program counter or
stack pointer.
    However, if you think GDB should simply search
farther back
from 0x658 for code which looks like the beginning of
a
function, you can increase the range of the search
using the `set
heuristic-fence-post' command.
warning: GDB can't find the start of the function at
0x658.
Previous frame identical to this frame (corrupt
stack?)
(gdb) t
[Current thread is 1 (process 362)]
(gdb) bt
#0  0x00000658 in ?? ()
#1  0x00000658 in ?? ()
(gdb) info registers
          zero       at       v0       v1       a0    
  a1       a2       a3
 R0   00000000 2ab01970 00000000 00000338 00000000
00000000 00000000 00000db0
            t0       t1       t2       t3       t4    
  t5       t6       t7
 R8   0dafd6e5 00000001 2abccfd4 2abc8034 00000001
2aac2948 00000001 2abe0ce4
            s0       s1       s2       s3       s4    
  s5       s6       s7
 R16  00400f70 7fff7e74 00400ed0 00000001 00400c70
00000000 10010f80 00000000
            t8       t9       k0       k1       gp    
  sp       s8       ra
 R24  00000263 2ad2c788 2af318b5 00000000 2af8dab0
7fff7bf0 7fff7bf0 2abe0ce4
            sr       lo       hi      bad    cause    
  pc
      00800008 00108413 0001b4e9 800649b8 2ad2c7c8
00000658
           fsr      fir
      00000000 00000000
(gdb)

Regards,
Brian

--- Daniel Jacobowitz <dan@debian.org> wrote:
> On Thu, Apr 07, 2005 at 10:44:54AM -0700, Brian
> Kuschak wrote:
> > Is anyone succesfully using gdb for mipsel to
> debug
> > core dumps?  If so, can you share your secrets for
> > success?  I tried various recent versions (6.3,
> > 6.1.1), but backtrace never works right, even
> though
> > the stack pointer appears to be valid.  gdb-5.3
> > partially works, but not completely.  
> 
> Give the CVS version a try, please.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery, LLC
> 
> 


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 

Re: gdb backtrace with core files

[Greg Weeks]

Brian Kuschak wrote:

>Is anyone succesfully using gdb for mipsel to debug
>core dumps?  If so, can you share your secrets for
>success?  I tried various recent versions (6.3,
>6.1.1), but backtrace never works right, even though
>the stack pointer appears to be valid.  gdb-5.3
>partially works, but not completely.  
>
>Forcing gdb to use a specific stack pointer and PC
>(frame <sp> <pc>) doesn't seem to help either.  
>
>Using linux 2.4.25 and gcc 3.3.3.
>
>  
>
It appears to work for me. My gdb has a ton of patches from Amit Kale 
though. The kernel is the latest malta with a couple of patches that 
shouldn't affect gdb.

-bash-2.05b# gdb
GNU gdb TimeSys Linux (6.2.1-1rh)
Copyright 2004 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 "mipsel-linux".
(gdb) file gdb_core_tester
Reading symbols from 
/root/TestWare/TTS_2.4.2/command/gdb_man/gdb_core_tester...done.
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) core-file core.2045
Core was generated by `./gdb_core_tester'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/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  0x00400f48 in add_node (rootptr=0x1000105c, nodeval=193)
    at create_core.c:75
75              if(node_ptr->value.value >= nodeval) {
(gdb) bt
#0  0x00400f48 in add_node (rootptr=0x1000105c, nodeval=193)
    at create_core.c:75
#1  0x00400fcc in add_node (rootptr=0x10001048, nodeval=193)
    at create_core.c:81
#2  0x00400f74 in add_node (rootptr=0x10000140, nodeval=193)
    at create_core.c:76
#3  0x00400df8 in create_tree (rootptr=0x10000140) at create_core.c:38
#4  0x00400b4c in main (argc=1, argv=0x7f931b44) at main.c:25

Greg Weeks

Re: gdb backtrace with core files

[Daniel Jacobowitz]

On Thu, Apr 07, 2005 at 10:44:54AM -0700, Brian Kuschak wrote:
> Is anyone succesfully using gdb for mipsel to debug
> core dumps?  If so, can you share your secrets for
> success?  I tried various recent versions (6.3,
> 6.1.1), but backtrace never works right, even though
> the stack pointer appears to be valid.  gdb-5.3
> partially works, but not completely.  

Give the CVS version a try, please.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

gdb backtrace with core files

[Brian Kuschak]

Is anyone succesfully using gdb for mipsel to debug
core dumps?  If so, can you share your secrets for
success?  I tried various recent versions (6.3,
6.1.1), but backtrace never works right, even though
the stack pointer appears to be valid.  gdb-5.3
partially works, but not completely.  

Forcing gdb to use a specific stack pointer and PC
(frame <sp> <pc>) doesn't seem to help either.  

Using linux 2.4.25 and gcc 3.3.3.

Regards,
Brian 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com