I would still love to get a reaction to this from the gcc folks (now included):
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? 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. 3) If not, any chance of fixing this somehow? 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? The original problem description that triggered this discussion can be found at http://permalink.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3820 Thanks. Hans > -----Original Message----- > From: gc-boun...@napali.hpl.hp.com > [mailto:gc-boun...@napali.hpl.hp.com] On Behalf Of Ivan Maidanski > Sent: Saturday, April 10, 2010 6:20 AM > To: NIIBE Yutaka > Cc: g...@napali.hpl.hp.com > Subject: Re[2]: [Gc] On cancellation, GC_thread_exit_proc is > never called > > > Fri, 09 Apr 2010 17:45:47 +0900 NIIBE Yutaka <gni...@fsij.org>: > > > Ivan Maidanski wrote: > > > This seems to be equivalent to your first patch. > > > > It is equivalent for libgc build, but it doesn't touch any header > > files. > > > > My intention is to minimize impact by the change. > > > > For libgc users who include gc.h, the first/second patch of > mine would > > not be good. Even if a user use -fexceptions for her > application, the > > change of undefine __EXCEPTIONS forces to use > __pthread_register_cancel. > > With third patch, it is up to users. > > > > > Did you read > > > > http://permalink.gmane.org/gmane.comp.programming.garbage-collection > > > .boehmgc/3824 ? Why not to pull GC_inner_start_routine > out into a > > > separate file that isn't compiled with -fexceptions? > > > > Thanks for the pointer. I had not read it. I read it now. > > > > My opinion is that: > > > > (1) I would agree that it would be better to pull out > > GC_inner_start_routine into a separate file. > > > > Just FYI, I confirmed that it is not needed to separate it out, > > at least for current implementation. > > > > For current implementation, compilation of > pthread_support.c with > > no __EXCEPTIONS only affects compilation of > GC_inner_start_routine > > (specifically, pthread_cancel_push), no effect for > other routines. > > > > (2) Only undefining __EXCEPTIONS is better, I think. > > > > I think that compiling GC_inner_start_routine without > -fexceptions > > is overkill somehow. Yes, it means it goes with no > __EXCEPTIONS, > > but it also generates no .eh_frame section for > > GC_inner_start_routine. > > > > No .eh_frame section for GC_inner_start_routine would be OK, > > because it is almost starting point of a thread. > > > > One minor benefit: If we have .eh_frame section for > > GC_inner_start_routine, it is possible for a debugger to trace > > back to the beginning. This is perhaps only useful > for those who > > chase down to the detail of pthread_create > implementation, though. > > -- > > I could agree with You. But, again, it's up to Hans whether > to commit this patch or not. > > Bye. > _______________________________________________ > Gc mailing list > g...@linux.hpl.hp.com > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/ >
