X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10112092038.AA14146@clio.rice.edu>
Subject: Re: libemu and profiling (LONG) [Was: Re: Building a profiled version of
To: djgpp-workers AT delorie DOT com
Date: Sun, 9 Dec 2001 14:38:00 -0600 (CST)
Cc: rich AT phekda DOT freeserve DOT co DOT uk
In-Reply-To: <3C134C9D.D057D932@phekda.freeserve.co.uk> from "Richard Dawe" at Dec 09, 2001 11:35:57 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> > level by adding the following line to emudummy.c:
> > void mcount(int _to) {}
> 
> You beauty! That worked. Below is a diff for the fixes for src/libemu. OK
> to commit?

I would remove the setting of errno.  It may bring in extra code into the
DXE in some future environment we don't want or need.  The entire emudummy
stuff is to handle the eprintf stuff for debugging (from what I remember).
There are better ways to do this but it was never worth the time.  The
prototypes are overkill, but I don't see any problems in a commit.

>       double d = atan(0.123);
> 
> Using the math co-pro (387 not set or set to y) gives a result of
> 0.122385; using a patched emu387.dxe gives a result of 0.1. Shouldn't the
> results be the same or at least a little closer?

The accuracy of the emulator in some cases isn't very good - I don't know
if this is such a case.  WMEMU is more accurate.

> Also if I run the test with 387=y, rerun the test with 387=n and finally
> rerun the test with set 387=y, I get an 'Exiting due to signal SIGNOFP'
> error. The program gets stuck in a loop, repeatedly crashing with SIGNOFP.

The hardware flag in the chip got left in the emulate mode.
You may have confused the DPMI provider (they really don't like allowing
FP emulation.  Last chip not to have FP was a 486SX - and most of those
aren't supported under newer Windows.  So this code never gets used or
tested).  

> Here's a symify'd traceback for a crash in the middle of the loop:

It's looping.  Coprocessor is not available, but we do a _clear87 in the
exit code if one is detected.  Since 387=y forces it, infinite loop.
Maybe dpmiexcp should set _8087 = 0 if this exception happens, but I 
think you are warned about setting 387 someplace...

> Any ideas were I should look [next weekend/later in the week] to debug
> this? It feels like there may be some stale exception handler state left
> over from the 387=n case, but then again I know nothing about exception
> handlers!

Behavior may depend on environment and DPMI provider.