RE: FPU precision & signal handlers (bug?)

Gabriel Paubert
2002-03-08T11:54:39Z

On 7 Mar 2002, Eric Ries wrote:

> Yes, this is a quite tricky problem. Fortunately, in our situation we are
> extremely picky about just which calculations must be bit-for-bit consistent
> across machines, and try to keep those operations very simple. We have been
> doing this for some time on Intel hardware, and - apart from this signal
> handler issue - have never had any problems.

Intel but not IA-64 I presume ?

>
> > Right.
> > [Snipped the clear explanation showing that you've done your homework]
>
> Thanks :) I know how annoying it can be to put up with clueless posts on
> mailing lists.

Indeed :)

> > Actually, fxsave does not reset the FPU state IIRC (so it could be faster
> > for signal delivery to use fxsave followed by fnsave instead of the format
> > conversion routine if the FPU happens to hold the state of the current
> > process).
>
> That's an interesting thought. I didn't have a decent reference on MMX
> instructions while I was tracking this bug down, so I just assumed they were
> basically equivalent to their 387 counterparts.

I confirm.

> I don't see how this is a problem, because (as far as I can tell) there is
> no need to use the "default" control word at all. In the solution I propose,
> the FPU state is still saved before a signal handler call, and restored
> afterwards. It's just that during the signal handler execution, the control
> word is set to the process-global value. Keep in mind that, in the case that
> your signal handler has no floating-point instructions, the control word
> never has to be set, because no FINIT trap will be generated. So there's
> only a performance cost to those of us who use floating point in our signal
> handlers.

And where would you take the global value from ?

>
> > Therefore you certainly don't want to inherit the control word of the
> > executing thread. Now adding a prctl or something similar to say "I'd like
> > to get this control word(s) value as initial value(s) in signal handlers"
> > might make sense, even on other architectures or for SSE/SSE2 to control
> > such things as handle denormal as zeros or change the set of exceptions
> > enabled by default...
>
> I'm afraid I don't quite follow what you're suggesting here. Don't you
> always want “your” control word in any function that executes as part of
> your process?

But your control word is changed on the fly by the compiler for things as
trivial as float/double to int conversion. It is not as global and static
as you seem to believe.

Gabriel.