Date: Wed, 3 May 2000 11:43:34 +0300 (IDT)
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
Subject: Re: interrupt 0x75 limitation in Win95 ?
In-Reply-To: <200005021646.SAA07021@cerbere.u-strasbg.fr>
Message-ID: <Pine.SUN.3.91.1000503114139.4851C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody 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, 2 May 2000, Pierre Muller wrote:

> >>    This Win95 limitation can be important for programs using C++
> exceptions !!
> >
> >How are C++ exceptions related to this issue?  I don't think they use the 
> >FP exception or signals, do they?
> 
>    I don't know about C++ but in Delphi object pascal apparently
> the FPU exceptions are converted into software exception that can be handled
> like any other sofware exceptions and thus need to be
> able to support multiple time calls, which is the origin
> of this whole thread. 

Oh, I see: you are saying that programs which use C++ exceptions to
handle SIGFPE could fail to receive the exception.  Yes, this could be
a problem.

However, Andris tells us that signals are not used in C++ exceptions,
so I guess this isn't a problem after all.

>   For instance if you take GNU make Version  3.77 
> and run from it a program that raises such an exception 
> then its make itself that crashes with a SIGFPE !!

This probably means that we need to augment Make with special
treatment for SIGFPE when it invokes child programs.  Thanks for
pointing this out.

>   If  "make" would hook the interrupt 0x31 and remember addresses of the
> child 
> interrupt 0x75 handlers it could redirect the exception on the basis 
> of the selector part of the exception address in the FPU
> (basically trying to rectify the wrong behavior of WinXX !)

Oh, you want the parent to lcall the child's exception handler, like
dbgcomm.c does, yes?  I don't think this will work.  By the time the
parent program receives the FP exception, the child already exited.
So you cannot lcall it, because it's not there: its memory was
released, its descriptors were deallocated, etc.  You will be jumping
into the Great Void...