kgdb still broken?

[Kris Kennaway]

On Fri, Aug 19, 2005 at 11:28:14PM -0700, Marcel Moolenaar wrote:
> On Aug 19, 2005, at 7:53 PM, Kris Kennaway wrote:
> 
> >It's not making much sense of the backtrace though:
> >
> >(kgdb) bt
> >#0  doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233
> >#1  0x00000000c006a728 in db_fncall (dummy1=0, dummy2=0, dummy3=11,  
> >dummy4=0x16e9a41a0 "")
> >    at /usr/src.6/sys/ddb/db_command.c:486
> >#2  0x00000000c006a434 in db_command (last_cmdp=0xc040f940,  
> >cmd_table=0x0, aux_cmd_tablep=0xc03c8dc8,
> >    aux_cmd_tablep_end=0xc03c8de0) at /usr/src.6/sys/ddb/ 
> >db_command.c:401
> >#3  0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/ 
> >db_command.c:452
> >#4  0x00000000c006d0b8 in db_trap (type=1855603632, code=0) at /usr/ 
> >src.6/sys/ddb/db_main.c:221
> >#5  0x00000000c018d208 in kdb_trap (type=107, code=0,  
> >tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473
> >#6  0x00000000c02f6b4c in trap (tf=0x16e9a4630) at /usr/src.6/sys/ 
> >sparc64/sparc64/trap.c:307
> >#7  0x00000000c0048fe0 in tl1_trap ()
> >#8  0x00000000c0048fe0 in tl1_trap ()
> >Previous frame identical to this frame (corrupt stack?)
> >
> >Where ddb showed that the panic correctly (see my mail to -current
> >entitled 'panic: uma_small_alloc: free page still has mappings!').
> 
> How can you compare this backtrace with the one in the email. This
> backtrace is the result of a trap, not a panic. For a panic, KDB
> is entered via kdb_enter(), not kdb_trap() as it is in this case.

Regardless, this is what kgdb informed me was the backtrace for the
same thread that panicked and I traced with DDB and gdb53.

> It is a known issue that kgdb cannot unwind across traps right now.
> 
> >gdb53 also gets it right, but I can't examine other threads to see if
> >they had also panicked.
> 
> Do you mean that 'info threads' doesn't work or that 'thread <TID>'
> doesn't work in kgdb?

I mean that 'info threads' doesn't work in gdb53, which is the only
offline debugger one can use on sparc64 that obtains more or less
reliable traces.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20050820/a7793714/attachment.bin