Date: Tue, 14 Aug 2001 12:11:37 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.org> Cc: <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org>, Bruce Evans <bde@FreeBSD.org> Subject: RE: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <20010814114352.L9172-100000@besplex.bde.org> In-Reply-To: <XFMail.010813165443.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Aug 2001, John Baldwin wrote: > On 13-Aug-01 Bruce Evans wrote: > > The anti-reentrancy flag in Debugger() can probably be axed too. It > > is similarly half-baked and is now unnecessary for preventing reentrance > > via the keyboard interrupt handler. > > What if we hit a code path from the Debugger that calls the Debugger() function? Bad things, but not much different from what happens if we hit a code path that calls Debugger() when we entered the debugger in another way. > Esp. since we can call any function from ddb if we really want to... What tends to happen is that the Debugger() call looks like a fatal trap in in a call to a non-ddb function or in a (non-memory access) ddb command. Then ddb longjmp()s back to its command loop. Nothing bad happens to ddb, but the kernel can be left in an inconsistent state (e.g., with locks held when they would have been released if the function finished normally). Similarly for gdb. > I suppose we could use db_active to test for this? But that is ddb-specific.. db_active is essentially just a public copy of the db_global_setjmp_valid flag which is used to control the longjmp()s, so not much more can be done with it. The longjmp()s give the correct error handling in most cases -- you wouldn't want a fully recursive handling even if the debugger could do it. I've missed recursive handling mainly when I want to debug the debugger itself. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010814114352.L9172-100000>