www.delorie.com/archives/browse.cgi | search |
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...
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |