* why don't setjmp save MXCSR register and x87 control word? @ 2021-03-16 14:39 Fengkai Sun 2021-03-17 18:59 ` Adhemerval Zanella [not found] ` <41f234be-0fbe-0ae1-74be-084bab59bef6@linaro.org> 0 siblings, 2 replies; 4+ messages in thread From: Fengkai Sun @ 2021-03-16 14:39 UTC (permalink / raw) To: libc-help 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: why don't setjmp save MXCSR register and x87 control word? 2021-03-16 14:39 why don't setjmp save MXCSR register and x87 control word? Fengkai Sun @ 2021-03-17 18:59 ` Adhemerval Zanella [not found] ` <41f234be-0fbe-0ae1-74be-084bab59bef6@linaro.org> 1 sibling, 0 replies; 4+ messages in thread From: Adhemerval Zanella @ 2021-03-17 18:59 UTC (permalink / raw) To: libc-help 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <41f234be-0fbe-0ae1-74be-084bab59bef6@linaro.org>]
* Re: why don't setjmp save MXCSR register and x87 control word? [not found] ` <41f234be-0fbe-0ae1-74be-084bab59bef6@linaro.org> @ 2021-03-18 13:02 ` Fengkai Sun 2021-03-18 13:25 ` Adhemerval Zanella 0 siblings, 1 reply; 4+ messages in thread From: Fengkai Sun @ 2021-03-18 13:02 UTC (permalink / raw) To: Adhemerval Zanella; +Cc: libc-help 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: why don't setjmp save MXCSR register and x87 control word? 2021-03-18 13:02 ` Fengkai Sun @ 2021-03-18 13:25 ` Adhemerval Zanella 0 siblings, 0 replies; 4+ messages in thread From: Adhemerval Zanella @ 2021-03-18 13:25 UTC (permalink / raw) To: Fengkai Sun; +Cc: libc-help 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-03-18 13:25 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-16 14:39 why don't setjmp save MXCSR register and x87 control word? Fengkai Sun 2021-03-17 18:59 ` Adhemerval Zanella [not found] ` <41f234be-0fbe-0ae1-74be-084bab59bef6@linaro.org> 2021-03-18 13:02 ` Fengkai Sun 2021-03-18 13:25 ` Adhemerval Zanella
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).