Date: Tue, 26 Mar 96 8:12:45 MET From: Greg Lehey <lehey.pad@sni.de> To: bde@zeta.org.au (Bruce Evans) Cc: hackers@freebsd.org Subject: Re: kgdb / remote gdb of the kernel? Message-ID: <199603260715.IAA01278@nixpbe.pdb.sni.de> In-Reply-To: <199603260254.NAA15825@godzilla.zeta.org.au>; from "Bruce Evans" at Mar 26, 96 1:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >>> and frankly I'm not even sure how it would work while >>> single-stepping a kernel - getting a packet off the wire and >>> ... >> ... >> One obvious approach would be to leave interrupts enabled but change >> all the vectors on entering the debugger, such that most interrupts >> get ignored, and the ethernet interrupt goes to a special, >> stripped-down driver. Note also that the remote debug interface is in >> the kernel, and not a user process. > > Interrupts should be disabled in the debugger. Agreed. But there are various ways to "disable" interrupts. The one I was proposing was to stop them from doing anything, *except* in the case when we're communicating across the Ethernet. > Currently they are only disabled if they are disabled when the > debugger is entered. I'd say that's broken. > The debugger must be prepared to handle this case without using > interrupts, so it may as well handle all cases without using > interrupts. Interrupts shouldn't be enabled anyway, because they > might interfere with debugging. Currently they are handled sloppily > by not doing anything special. This has the benefit of keeping the > clocks running while you're debugging unless you're debugging a > clock interrupt handler or anything else running at a high cpl. The > debugger should be prepared to restore the clocks when in this case, > so it may as well restore the clocks in all cases and run with clock > interrupts disabled... Restoring the clocks is quite complicated. > See apm for how to do it wrong. The obvious way to restore the time-of-day clock would be from CMOS. Would this break anything else? > Ethernet is harder to support than serial because the hardware interface > is more complicated and you would have to write special drivers for about > 20 cards to get reasonable coverage. Yes, I hadn't thought about that. The only way to handle that without too much pain would be to have a second copy of the driver somewhere. I haven't even begun to think about what that would entail. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603260715.IAA01278>