From owner-freebsd-hackers  Fri Jan 24 09:41:22 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA09076
          for hackers-outgoing; Fri, 24 Jan 1997 09:41:22 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA09065;
          Fri, 24 Jan 1997 09:41:12 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id EAA24032; Sat, 25 Jan 1997 04:37:02 +1100
Date: Sat, 25 Jan 1997 04:37:02 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199701241737.EAA24032@godzilla.zeta.org.au>
To: bde@FreeBSD.org, julian@whistle.com
Subject: Re: Bruce! HHHEEELLLLPPPP!
Cc: hackers@FreeBSD.org
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>can you tell me what I should do to make the interrupt from sio1
>bust it's way in through ANYTHING so that I can put a breakpoint
>on it and try get a stacktrace when the thing freezes by sending
>a character in? 

BREAK_TO_DEBUGGER or just a breakpoint on siointr() should already
allow sio activity to interrupt almost anything and give control
to ddb.  You can't do any better without an NMI.

>is this the sort of thing you could trap with the "Bruce debugger?"

It wouldn't help grab control.  Once it gets control it can single
step better, unless cpu interrupts are already masked (as they are
in siointr()).  ddb doesn't mask cpu interrupts itself, so it never
gets full control unless interrupts are already masked.  Change the
debugger trap gates in machdep.c to interrupt gates and remove the
`sti' from BPTTRAP() in exception.s to fix this.  More is required
to keep control while single stepping.

Bruce