This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug math/21035] longjmp() resets FPU exception mask


https://sourceware.org/bugzilla/show_bug.cgi?id=21035

Nadav Har'El <nyh at math dot technion.ac.il> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #5 from Nadav Har'El <nyh at math dot technion.ac.il> ---
Hmm, on second thought, I think this actually *is* a sigsetjmp()/siglongjmp()
problem:

If I understand correctly, when the kernel starts a signal handler, it saves
the FPU state (including the control word) and then sets some "sane default" so
the handler can run without having to guess what kind of messed up state the
application was in when the signal occurred. I'm guessing this "sane default"
probably has all the FPU exceptions masked, because this is what FNINIT does by
default.

If this is what happens, then sigsetjmp/siglongjmp needs to save the FPU state
- including the control word - as they were during the time of sigsetjmp. If
they don't, instead of restoring the correct fpu control word, we'll be left
with the "sane default" that the signal handler left us with.

Apparently this issue has been known for many years: see for example:
https://bugs.openjdk.java.net/browse/JDK-6292965
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069337.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]