[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