Message-Id: <200001041110.MAA10042@cerbere.u-strasbg.fr> X-Sender: muller AT ics DOT u-strasbg DOT fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 04 Jan 2000 12:06:57 +0100 To: djgpp-workers AT delorie DOT com, Charles Sandmann From: Pierre Muller Subject: Re: GDB, DOS 6.22, CWSDPMI and Interrupts References: <9912301605 DOT AA15338 AT clio DOT rice DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: djgpp-workers AT delorie DOT com At 11:30 02/01/00 +0200, Eli Zaretskii wrote: > >On Thu, 30 Dec 1999, Charles Sandmann wrote: > >> 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! But this would still mean that a program would behave differently within the debugger than alone ! Even if I agree its probably better than nothing I still think that its a poor's man solution ! >Okay, a referendum: how many people out there debug code that disables >interrupts? > >For this to matter, you need to put a breakpoint in, or single-step >through, such code. How many people do that? Probably not many ! But debugging code that disable interrupt and call int 0x31 inside the disabled code will then face the problem that the code after it could be interrupted while the coder explicitly forbids it !! Another suggestion : Lets us simply say that the call to int 0x31 should never change the interrupt state then we store the interrupt state before calling the true interrupt handler and restore the state afterwards!! WARNING functions 0x900 0x901 need special handling then !! (these are the two function that explicitly change the interrupt state !) (what does 0x902 remark in Ralph Brown Interrupt list mean ??) Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller AT ics DOT u-strasbg DOT fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99