From owner-freebsd-current  Thu Apr 25 09:35:54 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id JAA20464
          for current-outgoing; Thu, 25 Apr 1996 09:35:54 -0700 (PDT)
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 JAA20456
          Thu, 25 Apr 1996 09:35:49 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id CAA31199; Fri, 26 Apr 1996 02:24:29 +1000
Date: Fri, 26 Apr 1996 02:24:29 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199604251624.CAA31199@godzilla.zeta.org.au>
To: bde@zeta.org.au, lehey.pad@sni.de
Subject: Re: request for a new "feature" as regards DDB
Cc: current@freebsd.org, gpalmer@freebsd.org, smpatel@umiacs.umd.edu
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.

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

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

Bruce