Re: [PATCH] Memory fencing problem in pthread cancellation

[Jeff Law <law at redhat dot com>]

On 01/15/2013 04:33 PM, Mike Frysinger wrote:
> the ia64 part looks (and runs) fine.
>
> > -  if (__builtin_expect (libgcc_s_personality == NULL, 0))
> > +  if (__builtin_expect (libgcc_s_handle == NULL, 0))
>
> while you're here, might i suggest also doing:
> 	if (__glibc_unlikely (libgcc_s_handle == NULL))
Not a bad idea.  I've always hated the __builtin_expect syntax as it 
makes it too easy to mis-read the code.

> perhaps we should even go further and make this an inline func in
> nptl/sysdeps/pthread/unwind-forcedunwind.c ?
> static __always_inline void
> _maybe_pthread_cancel_init (void)
> {
>    if (__glibc_unlikely (libgcc_s_handle == NULL))
>      pthread_cancel_init ();
>    else
>      atomic_read_barrier ();
> }
>
> that way it's harder for arches to screw up because they just call:
> 	_maybe_pthread_cancel_init ();
> and all the magic logic stays in the common unwind file
Seems like a good ideas as well.  It'll have to be duplicated for arm 
since arm provides a full replacement rather than #including the generic 
unwind-forcedunwind.c.

jeff