[PATCH 1/3] nptl: Move pthread_sigmask implementation to libc

[Florian Weimer]

* Adhemerval Zanella:

> On 13/03/2020 10:16, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> On 13/03/2020 06:51, Florian Weimer wrote:
>>>> * Adhemerval Zanella via Libc-alpha:
>>>>
>>>>> diff --git a/sysdeps/unix/sysv/linux/aarch64/libc.abilist b/sysdeps/unix/sysv/linux/aarch64/libc.abilist
>>>>> index a4c31932cb..694efeb1e4 100644
>>>>> --- a/sysdeps/unix/sysv/linux/aarch64/libc.abilist
>>>>> +++ b/sysdeps/unix/sysv/linux/aarch64/libc.abilist
>>>>> @@ -1447,6 +1447,7 @@ GLIBC_2.17 pthread_self F
>>>>>  GLIBC_2.17 pthread_setcancelstate F
>>>>>  GLIBC_2.17 pthread_setcanceltype F
>>>>>  GLIBC_2.17 pthread_setschedparam F
>>>>> +GLIBC_2.17 pthread_sigmask F
>>>>>  GLIBC_2.17 ptrace F
>>>>>  GLIBC_2.17 ptsname F
>>>>>  GLIBC_2.17 ptsname_r F
>>>>> diff --git a/sysdeps/unix/sysv/linux/aarch64/libpthread.abilist b/sysdeps/unix/sysv/linux/aarch64/libpthread.abilist
>>>>> index d65beba958..48b368acb1 100644
>>>>> --- a/sysdeps/unix/sysv/linux/aarch64/libpthread.abilist
>>>>> +++ b/sysdeps/unix/sysv/linux/aarch64/libpthread.abilist
>>>>> @@ -156,7 +156,6 @@ GLIBC_2.17 pthread_setconcurrency F
>>>>>  GLIBC_2.17 pthread_setname_np F
>>>>>  GLIBC_2.17 pthread_setschedprio F
>>>>>  GLIBC_2.17 pthread_setspecific F
>>>>> -GLIBC_2.17 pthread_sigmask F
>>>>>  GLIBC_2.17 pthread_sigqueue F
>>>>>  GLIBC_2.17 pthread_spin_destroy F
>>>>>  GLIBC_2.17 pthread_spin_init F
>>>>
>>>> This change is not fully compatible: Newly-linked programs may incur
>>>> lazy binding failures on older glibc versions because pthread_sigmask
>>>> is not present in libc.so.6.
>>>
>>> But backward compatibility is not a fully support scenario. Do we
>>> really need to handle such cases for the libpthread removal
>>> project?
>> 
>> So far, our approach to symbol versioning has been that if the
>> application (or DSO) loads, it will not fail later due to a missing
>> symbol.  Some RPM-based distributions have no other mechanism to
>> ensure correct package dependencies.
>
> Yes, but my understanding was exactly that new loader behaviour
> (f0b2132b3524) will prevent the failure for this specific case.

No, the loader behavior change is for existing binaries linked against
an old libpthread.  It cannot handle new binaries which are not linked
against libpthread, but use pthread_sigmask.  These binaries will load
only if the process has loaded libpthread for another reason.