ivmai at mail.ru
Sat Apr 10 06:20:16 PDT 2010
Fri, 09 Apr 2010 17:45:47 +0900 NIIBE Yutaka <gniibe at 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
> 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
> 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.
More information about the Gc