delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/11/15/11:14:52

From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9811151608.AA14746@clio.rice.edu>
Subject: Re: DPMI implementation related problem in crt0.S
To: djgpp-workers AT delorie DOT com
Date: Sun, 15 Nov 1998 10:08:47 -0600 (CST)
In-Reply-To: <Pine.A41.4.05.9811141927180.65238-100000@ieva01.lanet.lv> from "Andris Pavenis" at Nov 15, 98 10:05:59 am
X-Mailer: ELM [version 2.4 PL20]
Reply-To: djgpp-workers AT delorie DOT com

> Seems that there is one DPMI related problem with debugging
> DJGPP programs.
> 
> DOS session under Win95: no problems
> 
> plain MS-DOS 7.0 without Win95 loaded (with and without EMM386):
> 	I found that some DPMI calls (first is fn 0Ah: creating alias
> 	for descriptor) returns with interrupts disabled when
> 	called from programs being debugged. It is in very begin
>         crt0.S. There are another places where this happens, but 
> 	currently I hadn't time to track them down. 
> 
> 	I tested this with DJGPP 2.02 beta. Seems that problem 
> 	may be related with hooking int 31h in dbgcom.c as
> 	it appears only when running program under debugger

dbgcom.c's hooking has always been a bit hairy - and it's been
changed a few times, so I can believe this.  There are two 
potential reasons which would explain the W95/DOS difference:
  IOPL - which will change the ability to change the interrupt flag
  W95 - has code to work around common bugs, like leaving interrupts disabled

Since DOS should have the more lenient IOPL - this tends to say we
are doing an IRET with the disable flag on the stack.

By the way - it may depend on DOS version also - some versions like
to clear the interrupt flag when they get a chance.

It might be some subtile bug with the hardware too.  Have fun...

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019