Date: Wed, 29 Dec 1999 14:55:40 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: salvador cc: djgpp AT delorie DOT com Subject: Re: GDB, DOS 6.22, CWSDPMI and Interrupts In-Reply-To: <386A0341.BA78509@inti.gov.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 29 Dec 1999, salvador wrote: > > I have successfully run under GDB 4.18 programs that use setitimer, so > > interrupts are not disabled in general under a debugger. > > Did your program call any real mode stuff between interrupts? Nothing except printf, I think. It was a simple test program. I'm not sure I understand how does real-mode code enter the equation here. Are you telling that even a single mode switch is enough to re-enable interrupts for the rest of the program? Or are you telling that the interrupts are deferred until the CPU switches to RM? If the latter, then the timer tick will stop updating the system clock as long as the program doesn't cause a mode switch, right? If you write a test program that stays in PM for prolonged period of time, you should see a huge time error in the system clock when the program exits. Is that what happens under the debugger? > > Also, SIGINT > > uses the keyboard interrupt, so if your program gets SIGINT when run > > under a debugger, interrupts are not disabled. > > No, I'm not getting SIGINT. So what *does* happen when you press Ctrl-C while the program runs under a debugger? > Perhaps you overlooked the most important detail: If *I* call a real mode service > periodically interrupts work because they seems to be enabled during the PMode->Real > Mode->PMode switch. No, I think I did manage to understand that part.