Date: Sun, 9 May 1999 12:29:52 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: DJ Delorie , djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu, Andris Pavenis Subject: Re: __dpmi_int causes trouble in signals In-Reply-To: Message-ID: 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 Mon, 3 May 1999, I wrote: > Here's a solution that seems to work. It forces the normal DS selector > into SS if it finds SS holding the DS alias. Comments? > > *** src/libc/go32/exceptn.S~ Mon May 3 11:04:26 1999 > --- src/libc/go32exceptn.S Mon May 3 11:38:28 1999 > *************** > *** 127,132 **** > --- 127,138 ---- > je 1f > cmpw %ax,32(%ebp) > je stack_ok > + .byte 0x2e /* CS: */ > + movw ___djgpp_ds_alias,%di > + cmpw %di,32(%ebp) > + jne 1f > + movw %ax,32(%ebp) > + jmp stack_ok > 1: movl $exception_stack+8000, 28(%ebp) > movw %ax, 32(%ebp) > stack_ok: Okay, I tested the change for exceptn.S in both DOS and Windows 95. I used a test program which I will add to djtst distribution (if you want it, use the anonymous CVS to check-out tests/libc/go32/signals.c) and didn't see any problems, although I left the program to run for an hour. The problem with SIGFPEs that stop at some point seems to be caused by an exception (like SIGINT or SIGALRM) in the middle of the SIGFPE handler; adding _clear87() to all the other signal handlers solved this. In any case, this also happens with stock v2.02, so it's not a new problem. (As an aside, it almost seems like we needed to call `_clear87' inside the exception processor in dpmiexcp.c, to prevent such subtle problems. But handlers for SIGFPE might want to examine the x87 status, so this is a bit complicated, and we probably shouldn't do it before v2.03.) So I think this change is safe enough to check into the source tree. If somebody disagrees, please speak up.