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

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

[Fengkai Sun]

Hi list,

To the best of my knowledge, setjmp have to save all the callee-saved
registers.

According to Sys V ABI:
>  The control bits of the MXCSR register are callee-saved (preserved
across calls), while the status bits are caller-saved (not preserved).
>  The x87 status word register is caller-saved, whereas the x87 control
word is callee-saved.

But in sysdeps/x86_64/setjmp.S, __sigsetjmp only saves rbx, rbp, r12-r15,
rsp.

I also found an example in FreeBSD, which makes more sense to me:
https://svnweb.freebsd.org/base/head/lib/libc/amd64/gen/_setjmp.S?view=markup

I don't know if there will be any problem if MXCSR and x87 control word are
not saved and get clobbered .


Best,
Fengkai

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

[Adhemerval Zanella]

On 16/03/2021 11:39, Fengkai Sun via Libc-help wrote:
> Hi list,
> 
> To the best of my knowledge, setjmp have to save all the callee-saved
> registers.
> 
> According to Sys V ABI:
>>  The control bits of the MXCSR register are callee-saved (preserved
> across calls), while the status bits are caller-saved (not preserved).
>>  The x87 status word register is caller-saved, whereas the x87 control
> word is callee-saved.
> 
> But in sysdeps/x86_64/setjmp.S, __sigsetjmp only saves rbx, rbp, r12-r15,
> rsp.
> 
> I also found an example in FreeBSD, which makes more sense to me:
> https://svnweb.freebsd.org/base/head/lib/libc/amd64/gen/_setjmp.S?view=markup
> 
> I don't know if there will be any problem if MXCSR and x87 control word are
> not saved and get clobbered .

Because afaik the C standard specify that any state of floating-point status 
flag should *not* be saved:

  7.13 Nonlocal jumps <setjmp.h>
  [...]
  It does not include the state of the floating-point status flags, of open files, 
  or of any other component of the abstract machine.

And the FreeBSD implementation seems to deviate from standard deliberately,
the commit 64c2e4665060b5f4 states:

  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.

And I am not sure, but skimming through kernel sources Linux does not
clobber the FPU state on signal handler entry.

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

[Fengkai Sun]

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?

I still have one question here:

On Thu, Mar 18, 2021 at 2:59 AM Adhemerval Zanella <
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.


Much appreciated,
Fengkai

Re: 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.