From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <9912301605.AA15338@clio.rice.edu> Subject: Re: GDB, DOS 6.22, CWSDPMI and Interrupts To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii) Date: Thu, 30 Dec 1999 10:05:51 -0600 (CST) Cc: salvador AT inti DOT gov DOT ar, djgpp-workers AT delorie DOT com In-Reply-To: from "Eli Zaretskii" at Dec 30, 99 09:23:46 am X-Mailer: ELM [version 2.4 PL20] Content-Type: text Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > like the culprit is in the following fragment from _i31_hook ... > This fragment survived unaltered since at least v2.01 (and I suspect > in v2.0 as well), the only changes were that more and more functions > of Int 31h are hooked and pass through this code. I think this > explains why all debuggers, including the old ports, exhibit the bug. > > Can someone spot what's wrong with this code and suggest how to repair > it? Have you ever written prototype code in a short time, trying to prove a concept without worrying about the details - knowing it needs to be reviewed, designed and re-written ... and then the code becomes production without review? Welcome to dbgcom.c! I don't remember any of the details of that code - it was written in a haze in a few hours early in the morning to show how to debug under DPMI. There is all sorts of ugliness in DPMI about if the interrupt flag is set on an IRET - it depends on IOPL and that's not uniform across the DPMI providers. There's a real good chance that none of that is considered in the debugger - prototyped on one environment. > Until the problem is solved in dbgcom.c, a work-around would be to > insert __asm__("sti") at the beginning of `main' and after each Actually, I think a better fix would be to modify DBGCOM to always enable interrupts on the stack before the IRET ... That's probably not exactly right either but it's probably a lot closer!