This is the mail archive of the libc-alpha@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]

Re: Add fetestexceptflag


On Mon, 29 Aug 2016, Florian Weimer wrote:

> Seeing the @assafe{} annotation makes me wonder:
> 
> How do signal handlers and these flags interact?  Are they reset upon normal
> termination of the signal handler, to the state they had at the start of the
> handler?  What about exiting the handler with siglongjmp?

I don't know what the Linux kernel does (and it might vary by architecture 
for all I know), but what we document is:

  Many functions that are AS-Safe may set @code{errno}, or modify the
  floating-point environment, because their doing so does not make them
  unsuitable for use in signal handlers.  However, programs could
  misbehave should asynchronous signal handlers modify this thread-local
  state, and the signal handling machinery cannot be counted on to
  preserve it.  Therefore, signal handlers that call functions that may
  set @code{errno} or modify the floating-point environment @emph{must}
  save their original values, and restore them before returning.

(to some extent with an eye to powerpc soft-float where the floating-point 
environment is just ordinary TLS variables, not processor state the kernel 
can save and restore), and what C11 says is (5.1.2.3#5):

  When the processing of the abstract machine is interrupted by receipt of 
  a signal, the values of objects that are neither lock-free atomic 
  objects nor of type volatile sig_atomic_t are unspecified, as is the 
  state of the floating-point environment. The value of any object 
  modified by the handler that is neither a lock-free atomic object nor of 
  type volatile sig_atomic_t becomes indeterminate when the handler exits, 
  as does the state of the floating-point environment if it is modified by 
  the handler and not restored to its original state.

(which allows both for the kernel to set a known state for signal 
handlers, or for it to leave the state as of the code that was interrupted 
by the signal, which might include changes to the rounding mode etc. made 
temporarily by library code, and for it to restore the state or not on 
exit from the signal handler as long as the case of a signal handler that 
leaves the state unchanged works correctly).

-- 
Joseph S. Myers
joseph@codesourcery.com


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