kgdb still broken?

[Marcel Moolenaar]

On Aug 20, 2005, at 11:27 AM, Kris Kennaway wrote:

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

I guess I just don't understand what's you're saying then. The
backtrace above clearly and reliably tells me that the core was
created by calling doadump() from within DDB. Such a backtrace
cannot be obtained from within DDB itself. I don't know what you
get with gdb53, but it should give you the same backtrace, unless
it shows the backtrace of a different thread or you were working
on a different core file altogether.

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

What exactly is unreliable about backtraces in kgdb?

-- 
  Marcel Moolenaar         USPA: A-39004          marcel at xcllnt.net