why don't setjmp save MXCSR register and x87 control word?

[Adhemerval Zanella]

On 18/03/2021 10:02, Fengkai Sun wrote:
> Hello Adhemerval,
> 
> Thank you very much for your informative reply!
> 
> I think I've figured it out: setjmp and longjmp, though look like function call 
> and return, are actually not. Thus their behavior should be defined by standard
>  instead of calling conventions, is that correct?

The C standard defines its semantic, it is up to the compiler plus the ABI
to actually define its calling convention  (gcc for instance handles internal 
the concept that setjmp returns more than once).

> 
> I still have one question here:
> 
> On Thu, Mar 18, 2021 at 2:59 AM Adhemerval Zanella <adhemerval.zanella@linaro.org <mailto:adhemerval.zanella@linaro.org>> wrote:
> 
>       Note that standards don't require longjmp to restore either control
>       word, and none of Linux, MacOS X 10.3 and earlier, NetBSD, OpenBSD,
>       or Solaris do it. However, it is historical FreeBSD behavior, and
>       bde points out that it is needed to make longjmping out of a signal
>       handler work properly, given the way FreeBSD clobbers the FPU state
>       on signal handler entry.
> 
>  
> Does this mean that on FreeBSD, after longjmp to the saved context, the FPU
>  state will be restored to what it was right after setjmp, while on other OSs it's not? 
> Because the situation I think of is that, the call stack between setjmp and longjmp
>  may have operations modifying FPU state, but longjmp does not restore it on 
> most OSs.
> 

No idea about FreeBSD, I am just quoting its setjmp commit history (I haven't
checked FreeBSB source or did any experiment to attest it). And yes, you can't
count that the FP state will be saved/restored over different implementations.