Date: Thu, 25 Apr 96 18:39:39 MDT From: Greg Lehey <lehey.pad@sni.de> To: bde@zeta.org.au (Bruce Evans) Cc: current@freebsd.org Subject: Re: request for a new "feature" as regards DDB Message-ID: <199604251639.SAA20877@nixpbe.pdb.sni.de> In-Reply-To: <199604251624.CAA31199@godzilla.zeta.org.au>; from "Bruce Evans" at Apr 26, 96 2:24 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >>> 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. > > Yes. > >>> 2. ddb actually doesn't disable interrupts. It even enables them if > >> 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 > > It's a bug. > >> 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. > > The debugger has to work when it is entered with all interrupts enabled, > so it sometimes can't depend on interrupts. Whatever it does to handle > that cause should work in all cases. I think we're agreed on all this. >>> a. polling is non-destructive. This makes it difficult to use timer0, >>> timer1 and the RTC. Perhaps they can be read without (destructively) > >> The way I propose it, you're going to have to poll the keyboard. >> That's the tradeoff. > > Polling the keyboard is destructive too. It took me many hours over > many months to learn how to poll the keyboard on XTs. Early attempts > used the 8259 to poll for interrupts. This didn't work well because it > changed the state of the 8259. AT keyboards are much easier. Do we still need support for XT keyboards? :-) Lowbug polls the keyboard, and I haven't had any problems with it. >>> b. the clock hasn't stopped. > >> Or that you can read the counters. I believe this to be the case. Is >> it? > > And that you can read the counters. The counters for timer0-3 are > always readable. Only the counters for periods >= 1 second in the RTC > are readable. We're really only talking about a 30 second (or whatever) timeout here. The RTC counters would do just fine for that. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604251639.SAA20877>