-fexceptions introduces ABI incompatibility of sorts (was: RE:
Re: [Gc] On cancellation, GC_thread_exit_proc is never called)
Ian Lance Taylor
iant at google.com
Tue Apr 13 17:07:15 PDT 2010
"Boehm, Hans" <hans.boehm at 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
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.
More information about the Gc