Re: kgdb missing stack frames

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

Ian