From owner-freebsd-hackers Mon Mar 25 18:56:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA03637 for hackers-outgoing; Mon, 25 Mar 1996 18:56:55 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA03619 Mon, 25 Mar 1996 18:56:49 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id NAA15825; Tue, 26 Mar 1996 13:54:20 +1100 Date: Tue, 26 Mar 1996 13:54:20 +1100 From: Bruce Evans Message-Id: <199603260254.NAA15825@godzilla.zeta.org.au> To: jkh@time.cdrom.com, lehey.pad@sni.de Subject: Re: kgdb / remote gdb of the kernel? Cc: bde@freebsd.org, hackers@freebsd.org, pst@Shockwave.COM 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. Currently they are only disabled if they are disabled when the debugger is entered. 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. 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. Bruce