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: Remove -fexceptions configure test


* Joseph Myers <joseph@codesourcery.com> [2015-10-15 23:28:49 +0000]:
> On Thu, 15 Oct 2015, Roland McGrath wrote:
> 
> > What is the reason for -fexceptions in all those other places?  If
> > each is actually a uses-callbacks case, then we should use that
> > variable to clarify that in the documentation.  I think that's the
> > actual case for all the stdio cases, because they can lead to
> > callbacks via _IO_JUMPS.
> > 
> > Do we have any -fexceptions cases that are not actually uses-callbacks?
> 
> I think:
> 
> * If a function may be cancelled, it needs -fexceptions.  This includes 
> most functions doing I/O unless explicitly using non-cancellable I/O 
> functions.
> 
> * If the cancellation may occur from within an inline asm, not just at 
> function call points, -fasynchronous-unwind-tables is needed as well.  
> (I'm not sure what's going on with the few files using 
> -fasynchronous-unwind-tables without -fexceptions.)
> 

i think -fasynchronous-unwind-tables don't need -fexceptions
(currently).

-fasync* means unwind can propagate from anywhere, cleanups
are not run.

-fexcept* means unwind can propagate from calls and cleanups
and exception handlers are run.

but glibc does not use exception based cleanups for cancellation
so pthread_cleanup_push/pop don't need -fexcept* if -fasync* is
already provided (e.g. when inline asm is cancelled and there
is *_push/pop around it in the same tu).

(glibc does use explicit __attribute__((cleanup(foo))), but only
when unwind comes from calls and then -fasync* is not used,
-fexcept* is enough.)

this might change when the cancellation redesign work of
Adhemerval Zanella is committed, then glibc can change the
internal cancel cleanup handling to use exceptions i think.

(although that would still change the behaviour of pthread_once
visibly: the callback does not have to be compiled with unwind
tables now and pthread_once still runs the cleanups if the
callback is canceled.. but that stops working with exception
based cleanup).

> * If a function uses callbacks, it needs -fexceptions (both because the 
> callbacks might use interfaces that can be cancelled, and also because 
> they might throw exceptions).
> 
> * For all of the above, __THROW must not be used.
> 
> More than one of the above may apply to a function.  I don't know what 
> makes sense regarding makefile variables in such cases (I/O and callbacks, 
> for example).  And I don't know if we actually intend to allow exceptions 
> to be thrown and cancellation to occur for arbitrary callbacks.  
> (snprintf is marked __THROWNL - but custom printf handlers can be 
> registered.)
> 
> -- 
> 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]