From owner-freebsd-current Thu Apr 25 02:29:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA27761 for current-outgoing; Thu, 25 Apr 1996 02:29:53 -0700 (PDT) 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 CAA27726 for ; Thu, 25 Apr 1996 02:29:38 -0700 (PDT) Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id LAA21653 for current@freebsd.org; Thu, 25 Apr 1996 11:29:24 +0200 Message-Id: <199604250929.LAA21653@nixpbe.pdb.sni.de> Subject: Re: request for a new "feature" as regards DDB To: bde@zeta.org.au (Bruce Evans) Date: Thu, 25 Apr 96 11:29:17 MDT From: Greg Lehey Cc: gpalmer@freebsd.org, smpatel@umiacs.umd.edu, current@freebsd.org In-Reply-To: <199604250239.MAA01585@godzilla.zeta.org.au>; from "Bruce Evans" at Apr 25, 96 12:39 pm X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I had tried to take this thread off line. If you agree, please include Terry and erich@lodgenet.com (Eric L. Hernes) on the reply. >>>> While we're talking about DDB, can't we have it timeout in 30s if you >>>> don't hit a key (and then generate a core dump). >>> >>> Not really ... that would assume that the IRQ handlers were still >>> operational, which may not be the case. DDB should only be running if >>> all interrupts are disabled if I remember right (and if I don't, I >>> won't mind being corrected :-) ) > > Here are some corrections :-). > > 1. ddb should run with all interrupts enabled. It should also normally > keep interrupts disabled while tracing. Otherwise the system state > may change while you're looking at it. May I assume that you mean "disabled" above? Then I agree. > 2. ddb actually doesn't disable interrupts. It even enables them if > they were only disabled in the cpu. Thus breakpoints sections > protected by `enable_intr(); ... disable_intr();' or early in > Xintr*(), or in fastintr handlers don't work right. spl masking > works better. Normally ddb spends most of it's time sitting in the > console input routine at spltty() or higher. Other interrupts are > masked iff they are masked when ddb is entered. tty interrupts > aren't masked throughout unless they are masked when ddb is entered. > Clock interrupts usually aren't masked when ddb is entered, so the > clocks usually keep ticking away. I don't think I agree with this approach. This makes it impossible to debug interrupt handlers. I think that it's usually acceptable for the clocks to stop during a debugging session. Possibly we could include an option to restart them where necessary, but I think that having all interrupts enabled is asking for trouble. In Lowbug I took a rather simplistic approach to interrupts: I had a mask of the interrupts that I wanted to block, and another mask of the interrupts that I wanted passed to Lowbug. It caused problems, particularly with breakpoints. This is one of the areas I want to rethink. > 3. timeout() is unsuitable for use ddb. First, clk0 interrupts might be > masked when ddb is entered. Then ddb can't unmask them, so the > clk0 won't work. Second, ddb shouldn't depend on the timeout() code > to work. > >> Can we sit in a loop, while polling the keyboard for input? > > Yes, you can usefully poll the clock(s) while polling the keyboard, > provided: > > a. polling is non-destructive. This makes it difficult to use timer0, > timer1 and the RTC. Perhaps they can be read without (destructively) > latching the count. Even that steals some state if a non-debugging > part of the system has just latched the count. timer2 is probably > safe to use, because non-debugging parts of the system never access > it. The way I propose it, you're going to have to poll the keyboard. That's the tradeoff. > b. the clock hasn't stopped. Or that you can read the counters. I believe this to be the case. Is it? Greg