Re: kgdb missing stack frames

On Mon, 19 May 2003, Ian Dowse wrote:

> In message <20030519161526.T22357_at_gamplex.bde.org>, Bruce Evans writes:
> >On Sun, 18 May 2003, Ian Dowse wrote:
> >> 	#0  mi_switch () at ../../../kern/kern_synch.c:530
> >> 	#1  0xc01edb92 in ithread_schedule (ithread=0xc1898280, do_switch=1)
> >> 	    at ../../../kern/kern_intr.c:402
> >> 	#2  0xc034ad43 in sched_ithd (cookie=0xc1898280)
> >> 	    at ../../../i386/isa/ithread.c:77
> >> 	#3  0xc033e242 in cpu_idle () at ../../../i386/i386/machdep.c:1074
> >> 	#4  0xc01ed16c in idle_proc (dummy=0x0) at ../../../kern/kern_idle.c:11
> >4
> >> 	#5  0xc01ecea0 in fork_exit (callout=0xc01ed130 <idle_proc>, arg=0x0,
> >> 	    frame=0x0) at ../../../kern/kern_fork.c:792
> >>
> >> i.e, the cpu_idle() frame now appears instead of Xintr14().
> >
> >This is no better, since it loses Xintr14()'s frame instead of cpu_idle()'s
> >frame.
>
> True, although Xintr14() doesn't have a real stack frame (and I
> don't know to make gdb expand one frame with an associated trap
> frame into two frames in the backtrace :-). In the case of traps
> (which are more common in bug reports), the frame that actually
> caused the trap is generally far more useful than seeing that
> calltrap() was called by trap().

Neither do I, but I know that it more or less works in ddb using the
magic names "Xintr*" and "calltrap" to decide when to do special frame
handling.  At least on i386's ddb's special frame handling for interrupts
starts working when Xintr* calls the interrupt handler and the interrupt
handler sets up its frame.  ddb doesn't have the detailed knowledge of
the stack state at every instruction in Xintr* that it would need to do
better.  gdb knows about the magic names too, but apparently doesn't
do as much with them as ddb (kvm-fbsd.c seems to only understand tf_eip
in trap frames, while db_nextframe() understands tf_ebp and tf_esp too.
I may have broken this in kvm-fbsd.c rev.1.9.  Rev.1.8 seems to be the
last version that references tf_ebp.  Rev.1.8 uses code much like the
current code that finds tf_eip to find tf_ebp instead.

Bruce