Date: Tue, 4 Jan 2000 14:21:55 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
cc: djgpp-workers AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject: Re: GDB, DOS 6.22, CWSDPMI and Interrupts
In-Reply-To: <200001041110.MAA10042@cerbere.u-strasbg.fr>
Message-ID: <Pine.SUN.3.91.1000104140837.27894D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Tue, 4 Jan 2000, Pierre Muller 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 !

It's clearly a kludgy solution, but given the fact that Charles is very 
busy, and that the _right_ solution probably involves fixing CWSDPMI,
do you have a better alternative?

Of course, if someone can suggest a change in CWSDPMI and get Charles'
blessing, we could do that instead.

> 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 !!

That's why I asked for opinions.  Personally, I don't expect many 
programs to call Int 31 inside code that runs with interrupts
disabled, but I might be wrong.

>   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!!

The current code in dbgcom.c already does that.  But Charles says that 
the problem might be inside CWSDPMI: it implements Int 31h handler as an 
interrupt, not as a call gate.  As far as I understood, this causes the 
interrupt flag to be reset *before* the hook installed by dbgcom.c is 
entered.  If this is the case, there's nothing we can do inside dbgcom.c 
to repair the situation except blindly set the interrupt flag.

> (what does  0x902 remark in Ralph Brown Interrupt list mean ??)

You mean this?

  Note:   should be used rather than PUSHF because that instruction yields 
          the physical interrupt state rather than the per-client virtualized
          interrupt flag

It means that if you need the virtualized IF, you need to call Int 31 
function 0902h instead of PUSHF (followed by POP EAX or some such), 
because the latter might bring the physical IF, the one that actually 
sits in the EFLAGS register.

I don't think this remark matters, except in the case where there are 
several Virtual Machines (i.e., on Windows or under a DPMI 1.0 provider).