RE: -fexceptions introduces ABI incompatibility of sorts (was: RE: Re[2]: [Gc] On cancellation, GC_thread_exit_proc is never called)

["Boehm, Hans" <hans dot boehm at hp dot com>]

[Removed gcc mailing list, added libc-alpha]

Thanks, Ian.  That's a good observation that I had missed. Thus I think the conclusions are:

1) We still have the problem that e.g. Linux programs that are composed of libraries compiled both with and without -fexceptions may not work correctly, in particular a -fexceptions version of bdwgc (to enable C++ support) doesn't work with a plain C application calling pthread_exit() because the bdwgc cleanup code is not invoked.

2) I'm still not sure what the right workaround for us is, but it only seems to be needed on systems that have both glibc, and for which bdwgc is compiled with -fexceptions, which exists mostly on gcc.  Is it reasonable to undefine _EXCEPTIONS to force old-fashioned handling of cleanup handlers?  Will that work reliably if the application code used with the collector uses exception-based cleanup?  Do we need two version of bdwgc (and possibly other libraries) depending on exception support?

3) We seem to have a documentation/packaging issue, in that -fexceptions seems to be an all-or-nothing proposition for the whole application, but nothing that I can find states that, and libraries seem to be shipped with one or the other, and no documentation as to which one was used.  At a minimum, should the Linux description of pthread_cleanup_push state that reliable invocation requires that either -fexceptions is not in effect when the call is compiled or any call the pthread_exit() or pthread_cancel() must also be compiled with -fexceptions?  Is that statement even correct? If not, what is the correct statement?

Hans

> -----Original Message-----
> From: Ian Lance Taylor [mailto:iant@google.com] 
> Sent: Tuesday, April 13, 2010 5:07 PM
> To: Boehm, Hans
> Cc: gcc@gcc.gnu.org; gc@napali.hpl.hp.com; Ivan Maidanski; 
> NIIBE Yutaka
> Subject: Re: -fexceptions introduces ABI incompatibility of 
> sorts (was: RE: Re[2]: [Gc] On cancellation, 
> GC_thread_exit_proc is never called)
> 
> "Boehm, Hans" <hans.boehm@hp.com> writes:
> 
> > 1) Is it intended that inconsistent use of -fexceptions can cause 
> > pthread cleanup handlers to be skipped (since exception 
> based cleanup 
> > is not invoked if thread exit is triggered from a context without 
> > exceptions), thus usually breaking code relying on pthread_cleanup 
> > handlers?
> 
> I don't know if I would use the word "intended," but I think 
> this is an expected and unavoidable consequence.
> 
> 
> > 2) If so, would it be appropriate to document that behavior?  In 
> > particular, several other options in the gcc manual 
> currently indicate 
> > that they introduce binary compatibility issues, while this 
> one does 
> > not.  This does seem to be basically a binary incompatibility issue.
> 
> Well, properly speaking, I don't think there is any binary 
> incompatibility in what gcc generates.  Code compiled with 
> and without -fexceptions can interoperate perfectly well.  I 
> can see that the way in which glibc uses _EXCEPTIONS to 
> decide how to handle pthread cleanups introduces an 
> incompatibility, but I think that is more an issue of how the 
> compiler is being used.
> 
> Of course more documentation is normally good, but in this 
> case what would the new documention say?  It seems that it 
> would amount to something like "If you compile code without 
> exception support, then any exception handlers in that code 
> will not be run."  It seems almost tautological.
> 
> I'm not trying to pick nits here.  glibc has chosen to 
> implement a cleanup mechanism which assumes that the code is 
> compiled entirely with or entirely without exception support. 
>  That's a choice made by the glibc maintainers, and any 
> restrictions that imposes are part of glibc, not gcc.  gcc 
> is, of course, used with libraries other than glibc, which 
> may or may not have similar problems.  I think gcc is making 
> a reasonable choice in permitting exceptions to be enabled or 
> disabled as the user prefers.
> 
> 
> > 3) If not, any chance of fixing this somehow?
> 
> I don't really see how.  Do you have any suggestions?
> 
> 
> > 4) Is the use of the __EXCEPTIONS macro in the library considered a 
> > stable part of the library interface?  Is it reasonable to 
> work around 
> > this problem by explicitly undefining it in user code?
> 
> gcc will reliably define _EXCEPTIONS as 1 when exceptions are 
> supported, and will reliably not define _EXCEPTIONS when 
> exceptions are not supported.  I can't speak to the library interface.
> 
> Ian
>