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

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?

[Joseph Myers]

On Wed, 17 Mar 2021, Adhemerval Zanella via Libc-alpha wrote:

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

Indeed, the floating-point exception flags, rounding mode and any other 
such state are essentially thread-local variables, and should be handled 
just like such variables.  setjmp and longjmp don't save and restore 
thread-local or global variables, so they shouldn't save and restore 
floating-point flags or control modes either.

(In psABI terms, we invented the term "limited-access bits" to describe 
this state in the 32-bit Power Architecture ABI.)

-- 
Joseph S. Myers
joseph@codesourcery.com