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 libc/22396] x86-64: siglongjmp does not restore PKRU register


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

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Thiago Jung Bauermann from comment #5)
> Also, the signal(7) man page mentions that "a  signal  handler  function 
> must be very careful", and provides a white list of functions which it can
> safely call. Calling an unsafe function causes undefined behavior. Neither
> longjmp() nor siglongjmp() are in the white list.
> 
> Given the above, is it reasonable for a program to call {sig,}longjmp() from
> a signal handler and expect it to work?

Yes, the most stringent restrictions only apply to asynchronous signals. 
Synchronous signals, such as SIGFPE due to integer division by zero, SIGBUS due
to access to the truncated part of a file mapping, or SIGSEGV due to a null
pointer dereference are delivered synchronously to the thread in question.  The
same can be true for signals sent explicitly.  In these cases, we must support
calling siglongjmp from a signal handler because it is an idiom which is often
employed by non-C language runtimes.

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