[PATCH] Add missing pthread_condattr_{init, destroy} stubs to libc

[Daniel Eischen]

On Nov 27, 2009, at 4:47 PM, Joe Marcus Clarke <marcus at FreeBSD.org>  
wrote:

> On Fri, 2009-11-27 at 16:19 -0500, Daniel Eischen wrote:
>> On Nov 27, 2009, at 2:14 PM, Joe Marcus Clarke <marcus at freebsd.org>
>> wrote:
>>
>>> On Fri, 2009-11-27 at 15:12 +0200, Kostik Belousov wrote:
>>>> On Fri, Nov 27, 2009 at 12:15:18AM -0500, Joe Marcus Clarke wrote:
>>>>> I would like permission to commit this patch which adds missing
>>>>> pthread_condattr_{init,destroy} symbols to libc.  I think I did  
>>>>> the
>>>>> symbol addition correctly (and it seems to work).  Without this,  
>>>>> the
>>>>> weak symbols added in the libpthread-stubs port conflict with
>>>>> those in
>>>>> libthr, and applications with use these symbols can crash.
>>>>>
>>>>> I have temporarily hacked libpthread-stubs to fix this, but I  
>>>>> really
>>>>> feel these stubs should be added to libc.  I've also copied kib as
>>>>> he
>>>>> has been kind enough to review my work in the past.  Thanks.
>>>>>
>>>>> http://www.marcuscom.com/downloads/stubs.diff
>>>>
>>>> It is FBSD_1.2 version that we use for symbols added after HEAD
>>>> become
>>>> CURRENT-9.
>>>
>>> Done.
>>
>> I don't think the symbols belong in FBSD_1.2.  They already exist in
>> libthr in a previous namespace.  If you use FBSD_1.2, then you
>> probably need to bump them in libthr and libc_r, and add compatible
>> symbols (no problem there since there are no differences) for the
>> previous versions.
>
> How would this be done?  Would I add an FBSD_1.2 namespace to
> pthread.map, or would FBSD_1.1 be sufficient?  How would the
> compatibility symbols be defined?

I'm away and on an iPhone, you'll have to search for my notes on this  
or see how it's been done for other libc compat symbols..

>
>> Still not sure why libc needs all libpthread stubs.  Shouldn't be
>> necessary.
>
> Agreed, but the problem comes with the libpthread-stubs port.  This  
> port
> was added as a dependency of libxcb (which is used by just about
> everything in X).  This port defines weak symbols for
> pthread_condattr_destroy and pthread_condattr_init and maps them to a
> function that simply returns 0.  The problem is that if a binary is
> linked to both this library and -pthread, and that binary calls
> pthread_condattr_init(), it can be resolved in libpthread-stubs  
> instead
> of libthr.  When this happens, the init isn't done, and any subsequent
> usage of the pthread_condattr_t structure results in a segfault.
>
> I'm certainly open to other suggestions for fixing this.

You can reference the non-weak underscore versions in libpthread, and  
when non-null you know libphread is present and just dereference  
them.  Or do something similar to libgcc (or is it libstdc++, I  
forget) and use pthread_create as you weakly referenced symbol.  The  
idea is that if the weakly reference symbol is present, then you know  
libpthread is present.  I may be misusing "reference" instead of  
"defined.

static void *create_is_present = pthread_create;
#pragma weak pthread_create

If create_is_present is not NULL then the symbol is present.

On travel, so I can't provide much more info right now.

--
DE