Date: Mon, 3 May 1999 10:02:17 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: DJ Delorie <dj AT delorie DOT com>
cc: djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu,
        Andris Pavenis <pavenis AT lanet DOT lv>
Subject: Re: __dpmi_int causes trouble in signals
In-Reply-To: <199905021432.KAA05556@envy.delorie.com>
Message-ID: <Pine.SUN.3.91.990503100043.4057N-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

Charles, Andris and others, could you please comment on what I suggest 
below?  Thanks.

On Sun, 2 May 1999, DJ Delorie wrote:

> >         FUNC(___dpmi_int)
> >         ENTER
> > 
> >         pushl   %es
> >         /* Win95 problem:  Add this next line */
> >         pushl   %ss
> >         movw    ___djgpp_ds_alias, %ax
> >         movw    %ax, %es
> >         /* Win95 Problem:  Add this next line */
> >         /* This should be ok since the app's SS and ___djgpp_ds_alias */
> >         /* have the same linear address space */
> >         movw    %ax, %ss

After some digging, I believe that there are two places in exceptn.S
which might need a change due to the above.

Let me remind that a hardware interrupt, such as a Ctrl-BREAK keypress
or a timer tick, is caught by a DJGPP interrupt handler, which
invalidates the DS selector by setting its limit to 4KB (the null
page).  When the program tries to access a DS- or SS-relative address,
this generates an exception that is processed by the function
`exception_handler' in exceptn.S.  Here is a fragment from that
function; it runs after the DS limit was already restored back to its
original value:

	movw	%cs:___djgpp_our_DS, %ds
	...
/* Change to our local stack on return from exception (maybe stack exception) */
	movw	%ds, %ax
	cmpb	$12,EXCEPNO(%ebx)		/* Stack fault ? */
	je	1f
	cmpw	%ax,32(%ebp)                     <<<<<<<<<<<
	je	stack_ok                         <<<<<<<<<<<
1:	movl	$exception_stack+8000, 28(%ebp)  <<<<<<<<<<<
	movw	%ax, 32(%ebp)                    <<<<<<<<<<<
stack_ok:
/* Now copy the exception structure to the new stack before returning */

Note the lines marked with "<<<<<<<<<<<".  If SS is loaded with the DS
alias selector when the exception strikes, this code will switch to
the exception stack.  This could happen if the exception is generated
inside __dpmi_int, after it puts the DS alias selector into SS.

I think if SS has the DS alias, such switch is not needed, and might
be dangerous if the signal handler runs complex code (the exception
stack is too small for anything serious).  If another signal is
generated while the handler for the first signal runs, this could
further complicate things.

Therefore, I suggest to add 2 new lines to the above fragment as shown
below:

	movw	%ds, %ax
	cmpb	$12,EXCEPNO(%ebx)		/* Stack fault ? */
	je	1f
	cmpw	%ax,32(%ebp)
	je	stack_ok
	cmpw	%cs:___djgpp_ds_alias,32(%ebp)   <<<< new line
	je	stack_ok                         <<<< new line
1:	movl	$exception_stack+8000, 28(%ebp)
	movw	%ax, 32(%ebp)
stack_ok:

Would people please see if this is a reasonable solution?

There is another similar fragment in exceptn.S, in the function called
__djgpp_save_interrupt_regs.  This function is only called by debugger
support in dbgcom.c, as far as I could see.  Andris, could you please
tell if you think a similar change is needed there as well?  In
particular, did you see some weird problems when interrupting a
debugged program in the middle of __dpmi_int, or putting a breakpoint
there?