Date: Thu, 25 Apr 96 11:29:17 MDT From: Greg Lehey <lehey.pad@sni.de> To: bde@zeta.org.au (Bruce Evans) Cc: gpalmer@freebsd.org, smpatel@umiacs.umd.edu, current@freebsd.org Subject: Re: request for a new "feature" as regards DDB Message-ID: <199604250929.LAA21653@nixpbe.pdb.sni.de> In-Reply-To: <199604250239.MAA01585@godzilla.zeta.org.au>; from "Bruce Evans" at Apr 25, 96 12:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604250929.LAA21653>