Re: [lmi] MinGW-w64 anomaly?

[Greg Chicares]

On 2016-12-25 16:36, Vadim Zeitlin wrote:
> On Sun, 25 Dec 2016 11:59:28 +0000 Greg Chicares <address@hidden> wrote:
[...]
> 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.

Perhaps it happened only with versions of msw predating the modern internet
era, so that there's no practical way to find the evidence now. Or perhaps
the evidence I heard was always mistaken, and the problem was never anything
other than loading a DLL into an application's process. In the confirmed
case where an external lmi user had this problem, I'm sure it wasn't any DLL
that we deliberately loaded, but maybe one was injected by some "security"
software e.g.: IOW, not a DLL loaded in a different process, but rather one
loaded into lmi's process by a different process.

lmi isn't the only application that checks the FP CW in idle time:

http://www.virtualdub.org/blog/pivot/entry.php?id=53
| VirtualDub contains a rather brute-force workaround for this problem
| ...will check for such issues whenever the primary message loop is idle.

Here's a case that specifically mentions DLL injection:

https://blogs.msdn.microsoft.com/dougste/2008/11/12/random-and-unexpected-exception_flt_divide_by_zero-and-exception_flt_invalid__operation/

And another:

https://randomascii.wordpress.com/2016/09/16/everything-old-is-new-again-and-a-compiler-bug/
| in the crazy world of Windows there are a lot of programs that think
| that injecting their DLLs into all processes is a good idea. ... And
| in this case one of these injected DLLs decided that changing the FPU
| exception flags in somebody else’s process was a good idea.

> 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).

Here, we should ask: "to what end? what decision would we change
depending on the answer to this question?" and that meta-question
seems to have a clear answer. If the only possible cause of this
problem is some possibly imaginary defect of msw that was probably
removed a decade ago, then we might even remove the FPU validation
as irrelevant today. But if it's possible for a badly-behaved DLL
to be injected into lmi's process outside our control and without
our knowledge--and clearly that is possible--then we should keep
the FPU validation, and even extend it to embrace SSE. Ruling out
the first possible cause wouldn't affect that decision. Thus,
where I had earlier proposed restricting lmi's idle-loop check to
the union of {x87, i386, msw} and you disagreed:

http://lists.nongnu.org/archive/html/lmi/2016-12/msg00063.html
| [...] But I'm not sure we really need to use LMI_MSW
| preprocessor checks: even if this code is not really needed under other
| platforms (although, again, in principle nothing prevents a GTK+ theme or
| macOS printer driver or whichever else shared library happens to be loaded
| in the process from wreaking havoc with MXCSR), there is no harm in keeping
| it there neither and fewer preprocessor checks the better IMO.

...I now endorse your proposal not to restrict that check, and
indeed to extend it to include MXCSR as well.