Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Thu, 3 Mar 2005 10:11:06 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: loading of wsock32 disturbs FPU
Message-ID: <20050303151106.GB30643@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <000701c51fc0$bc678550$f14861cb AT DANNY>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000701c51fc0$bc678550$f14861cb@DANNY>
User-Agent: Mutt/1.4.1i

On Thu, Mar 03, 2005 at 08:15:08PM +1300, Danny Smith wrote:
>cgf wrote:
>>On Wed, Mar 02, 2005 at 03:37:42PM +0100, Corinna Vinschen wrote:
>>>On Mar  2 15:31, Corinna Vinschen wrote:
>>>>On Mar 2 13:33, Dave Korn wrote:
>>>>>Hm.  We probably need to put a finit instruction into the autoload code
>>>>>somewhere.  wsock_init () looks like just the place......  now if I
>>>>>just persuade the CVS code to build without a SIG11 (grmbl grmbl....)
>>>>
>>>>Hmm?  -v please.
>>>
>>>I just added an finit call to wsock_init and it seems to work fine.
>>>
>>>Are there any non-FPU CPUs >= i386 out there which would choke on this
>>>machine instruction?  I guess not, but I'm not exactly fluent in ix86
>>>history...
>>
>>I mentioned to Corinna on irc that I don't think that just calling finit
>>is the right way to handle this.  What if someone had already set the
>>precision as they liked?  Then loading winsock would reset it.
>
>Seeing this I got a fright, thinking mingw would have the same problem, with
>very bad consequences for eg,
>libgcj.a, which _always_ loads ws2_32.dll, and many, many other projects
>
>But no, I get:
>
>FPU test OK
>FPU test OK
>FPU test OK
>FPU test OK

>I think ws2_32.dll calls _fpreset() which is normally supplied by msvcrt.dll
>Mingw provides its own _fpreset  in libmingwex.a (crt_fp10.o) )  which  sets
>64-bit mantissa so all is well

I'm confused.  Where would you put a _fpreset() such that it would be
called by ws2_32.dll?  I doubt that ws2_32.dll iterates over all of the
loaded dlls looking for this function.

This would appear to be working ok if ws2_32.dll is either loaded early
in the process or if it not dynamically loaded.  Things seemed to be
working fine for me when cygwin's thread was causing ws2_32.dll to be
loaded right away.

>If I load in mingw's crt_fp8.o module, which provides a stub for the msvcrt.dll
>import  _fpreset,  I get the error.

That would imply that this has to be linked into a progarm to work.  That's not
a solution for cygwin since it seems like it would require all cygwin programs
to be relinked.

>A cygwin version of _fpreset (that calls finit) should do the trick, without the
>overhead of  fpu environment  sav and restore

Maybe I'm missing something since I am not a floating point person but I
don't think saving/storing 16 bits to a location on the stack is too big
a price to pay for this.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/