From owner-freebsd-current  Thu Apr 25 09:40:03 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id JAA20709
          for current-outgoing; Thu, 25 Apr 1996 09:40:03 -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 JAA20654
          for <current@freebsd.org>; Thu, 25 Apr 1996 09:39:56 -0700 (PDT)
Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id SAA20877 for current@freebsd.org; Thu, 25 Apr 1996 18:39:39 +0200
Message-Id: <199604251639.SAA20877@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 18:39:39 MDT
From: Greg Lehey <lehey.pad@sni.de>
Cc: current@freebsd.org
In-Reply-To: <199604251624.CAA31199@godzilla.zeta.org.au>; from "Bruce Evans" at Apr 26, 96 2:24 am
X-Mailer: xmail 2.4 (based on ELM 2.2 PL16)
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>
>>> 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