[PATCH v3 25/37] nptl: Move pthread_getspecific, __pthread_getspecific into libc

Adhemerval Zanella adhemerval.zanella@linaro.org
Wed Mar 24 14:43:17 GMT 2021



On 24/03/2021 11:38, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>> diff --git a/nptl/Versions b/nptl/Versions
>>> index d44958f5b6..218d6bbbf8 100644
>>> --- a/nptl/Versions
>>> +++ b/nptl/Versions
>>> @@ -1,5 +1,6 @@
>>>  libc {
>>>    GLIBC_2.0 {
>>> +    __pthread_getspecific;
>>>      __pthread_key_create;
>>>      __pthread_once;
>>>      _pthread_cleanup_pop;
>>> @@ -29,6 +30,7 @@ libc {
>>>      pthread_equal;
>>>      pthread_exit;
>>>      pthread_getschedparam;
>>> +    pthread_getspecific;
>>>      pthread_key_create;
>>>      pthread_mutex_destroy;
>>>      pthread_mutex_init;
>>> @@ -88,8 +90,10 @@ libc {
>>>    }
>>>    GLIBC_2.34 {
>>>      __pthread_cleanup_routine;
>>> +    __pthread_getspecific;
>>
>> Why do we need a __pthread_getspecific for 2.34?
> 
> I can turn __pthread_getspecific into a compat symbol once tss_get has
> been moved into libc.  Then we do not need
> __pthread_getspecific@@GLIBC_2.34 anymore.

Right.

> 
> As discussed before, I do not want to introduce
> __pthread_getspecific@@GLIBC_PRIVATE because relinking applications
> which previously used the public __pthread_getspecific symbol will
> suddenly switch to the internal GLIBC_PRIVATE symbol, which would be a
> regression.
> 
> (__pthread_getspecific is not used by libstdc++.)

Yeah, I am still not 100% convinced that relinking should something
we should be constrained but it looks ok for now.


More information about the Libc-alpha mailing list