Re: [lmi] MinGW-w64 anomaly?

[Vadim Zeitlin]

On Sun, 25 Dec 2016 11:59:28 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-12-22 14:31, Vadim Zeitlin wrote:
GC> > On Thu, 22 Dec 2016 01:24:58 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> On 2016-12-21 23:43, Vadim Zeitlin wrote:
GC> > GC> > On Wed, 21 Dec 2016 22:49:50 +0000 Greg Chicares <address@hidden> 
wrote:
GC> > ...
GC> > GC> > GC> Testing some actual computation or computations instead seems 
like
GC> > GC> > GC> a strange and roundabout way of performing the same test.
GC> > GC> > 
GC> > GC> >  Really? It seems like much more direct way to me: after all, we're 
not
GC> > GC> > interested in preserving x87 control word, we just want to have the 
correct
GC> > GC> > results. And for the code compiled to use SSE instead of x87 
instructions
GC> > GC> > these are not at all the same thing, which is the source of the 
problem.
GC> > GC> 
GC> > GC> Yet the underlying problem is avoided completely, AIUI, with SSE.
GC> > 
GC> >  To play the devil's advocate, in principle, it's possible for a rogue DLL
GC> > to change the rounding mode and/or error handling bits in MXCSR register
GC> > too, why not?
...
GC> It's also possible in principle for another process to destroy the stack.
GC> Only an OS that's broken by design would allow that, of course, but it's
GC> possible.

 I'm not sure what are we discussing here, to be honest. Of course, it's
possible for an OS to be arbitrarily broken and even non-broken OS can fail
to protect the process stack from corruption by another process if they run
on a platform without MMU.

 What I'm saying is the converse of this, i.e. that it's not possible for
an OS, however perfect it is, to prevent a DLL from changing the control
word of the process this DLL is loaded into.


GC> You could run 'sample.cns' and time that, e.g.:
GC> 
GC> time wine ./lmi_cli_shared --file=/opt/lmi/src/lmi/sample.cns --accept 
--ash_nazg --data_path=/opt/lmi/data

 Thanks!


GC> The problem with at least some known versions of msw is that they
GC> failed to virtualize the x87 control word.

 I just looked for quite some time for any mention of this bug and couldn't
find it anywhere. All I found was that the early version of Win64
documentation _incorrectly_ stated that the state of x87 was not saved
across process switches, but this was (a) wrong and (b) never affected 32
bit versions. Everything I could find seems to indicate that the OS uses
F(N)SAVE instruction to preserve the full FPU state during the context
switches. It would take an actively perverse programmer to use some other
way of preserving floating point registers when the CPU provides a
dedicated instruction for this and it's very hard to believe that somebody
at Microsoft came up with such a way *and* that nobody else has apparently
ever noticed that happening.

GC> Even though lmi runs in its own process, loading another process could
GC> affect the CW in the lmi process.

 Sorry but I really need some evidence backing up this assertion before I
believe it. I still think that the observed behaviour was due to a badly
written DLL being loaded into the address space of the lmi process and not
to anything happening in another process.

 If you'd like to, I could write a test launching a process constantly
changing the x87 control word and verifying that its own control word
doesn't change and then run it on all versions of MSW I have access to (or
at least XP and later, I'm really not sure we want to be testing anything
earlier anyhow).

 Would you be interested in me doing this?
VZ