Mail Archives: cygwin/2005/03/03/10:11:20
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/
- Raw text -