Date: Mon, 8 Oct 2001 22:23:32 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: <current@FreeBSD.ORG> Subject: Re: Missing stack frames in kgdb/ddb traces Message-ID: <20011008214808.S17093-100000@delplex.bde.org> In-Reply-To: <200110072132.aa77889@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 7 Oct 2001, Ian Dowse wrote: > I noticed recently two problems with gdb/ddb traces that involve an > interrupt frame (both of these are in i386-specific code, but maybe > similar issues exist on other architectures): > > The first is that kgdb sometimes messes up a stack frame that > includes an interrupt, e.g in the trace below, the cpu_idle() frame > is corrupted. > > #7 0xc0325246 in siointr1 (com=0xc092a400) at machine/cpufunc.h:63 > #8 0xc0325137 in siointr (arg=0xc092a400) at ../../../isa/sio.c:1859 > #9 0x8 in ?? () > #10 0xc01ff391 in idle_proc (dummy=0x0) at ../../../kern/kern_idle.c:99 > #11 0xc01ff210 in fork_exit (callout=0xc01ff370 <idle_proc>, arg=0x0, > frame=0xc40ffd48) at ../../../kern/kern_fork.c:785 > > This is because gdb was never updated when cpl was removed from the > interrupt frame (ddb was changed in i386/i386/db_trace.c rev 1.37). > The following patch seems to fix it: Seems reasonable. > Secondly, fast interrupts do not have an XresumeN style of symbol, > so neither gdb nor ddb treat their frames as interrupt frames. > This causes the frame listed as XfastintrN to gobble up the frame > that was executing at the time of the interrupt, which is especially > annoying when a serial console is being used to debug an infinite > loop in the kernel. BTW, I think parts of the keyboard interrupt handler need to be fast interrupts again so that the keyboard can be used to debug infinite loops in the kernel like it used to be able to. Now the debugger hotkey always takes you to an uninteresting place in the keyboard ithread even if it is not blocked. > The following patch adds an XresumefastN to fast interrupt handlers, > which allows gdb and ddb to correctly see the missing frame. The > name Xresumefast is chosen because it involves no ddb or gdb changes > (they just check for a name beginning with "Xresume"). I think debuggers should be taught about the main entry points Xintr* and Xfastintr* instead. The current Xresume* labels are not used except by debuggers. These labels are only used by debuggers because they hide the labels for the main entry points of the interrupt handlers. Note that Xsyscall is already handled like this. I think support for it was broken in gdb by the evil syscall_with_err_pushed changes. I still use the old non-bloated frame for fast interrupt handlers so I would need special support for this frame type. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011008214808.S17093-100000>