kgdb still broken?

Marcel Moolenaar marcel at xcllnt.net
Sat Aug 20 19:31:04 GMT 2005


On Aug 20, 2005, at 12:09 PM, Kris Kennaway wrote:

>> What exactly is unreliable about backtraces in kgdb?
>>
>
> Wih gdb53 I see the following:
*snip*
> #5  0x00000000c018d200 in kdb_trap (type=107, code=0,  
> tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473
> #6  0x00000000c02f6b44 in trap (tf=0x16e9a4630) at /usr/src.6/sys/ 
> sparc64/sparc64/trap.c:307
> #7  0x00000000c018cddc in kdb_enter (msg=0x0) at /usr/src.6/sys/ 
> kern/subr_kdb.c:267
> #8  0x00000000c018cdd4 in kdb_enter (msg=0xc03a2650 "panic") at / 
> usr/src.6/sys/kern/subr_kdb.c:267
> #9  0x00000000c016e144 in panic (fmt=0xc03c4130 "uma_small_alloc:  
> free page still has mappings!")
>     at /usr/src.6/sys/kern/kern_shutdown.c:537
*snip*

> While the kgdb output is useless:
*snip*
> #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?)
*snip*

I see. As I said, kgdb cannot yet unwind across trapframes. Other
than that the backtrace seems to be reliable. Not being able to
unwind across backtraces is not particular to sparc64. kgdb cannot
do that on any platforms. Some platforms, i386 in particular, are
lucky in that kgdb is able to get out of the woods and pick up
the trail after being lost for a handful of frames. This is due
to the way backtraces work on those platforms.

As for the resolution: I've been working on a new import of gdb,
which allows us to register frame sniffers to handle this, but
gdb has changed internally in such a way that our threading
support cannot be compiled-in. This requires porting, which I
don't want to do because it needs to be rewritten to support all
platforms and merged into gdb. I don't see a point in fixing
backtraces at the cost of the partial threading support we have
now. In other words: it requires too much work for me to embark
on it right now.

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




More information about the freebsd-sparc64 mailing list