Date:	Wed, 29 Dec 1999 14:55:40 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	salvador <salvador AT inti DOT gov DOT ar>
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:	<Pine.SUN.3.91.991229144716.13248A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

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.

- Raw text -