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

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

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.