From owner-freebsd-hackers Mon Mar 25 23:16:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA16464 for hackers-outgoing; Mon, 25 Mar 1996 23:16:07 -0800 (PST) Received: from nixpbe.pdb.sni.de (mail.sni.de [192.109.2.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA16427 for ; Mon, 25 Mar 1996 23:16:00 -0800 (PST) Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id IAA01278 for hackers@freebsd.org; Tue, 26 Mar 1996 08:15:33 +0100 Message-Id: <199603260715.IAA01278@nixpbe.pdb.sni.de> Subject: Re: kgdb / remote gdb of the kernel? To: bde@zeta.org.au (Bruce Evans) Date: Tue, 26 Mar 96 8:12:45 MET From: Greg Lehey Cc: hackers@freebsd.org In-Reply-To: <199603260254.NAA15825@godzilla.zeta.org.au>; from "Bruce Evans" at Mar 26, 96 1:54 pm X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >>> 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