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

[Adhemerval Zanella]

On 13/03/2020 10:24, Florian Weimer wrote:
> * 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.
> 

That's not what I am seeing in fact. Based on my patchset, I changed
tst-sigisemptyset.c to call pthread_sigmask:

$ readelf -a signal/tst-sigisemptyset | grep "(NEEDED)"
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

$ LD_DEBUG=all ./elf/ld-linux-x86-64.so.2 --library-path .:./math:./elf:./dlfcn:./nss:./nis:./rt:./resolv:./mathvec:./support:./crypt:./nptl signal/tst-sigisemptyset --direct
[...]
     20190:     symbol=pthread_sigmask;  lookup in file=signal/tst-sigisemptyset [0]
     20190:     symbol=pthread_sigmask;  lookup in file=./libc.so.6 [0]
[...]

And checking with maps, libpthread was not loaded.

Off course, trying to use the system loader won't work:

$ signal/tst-sigisemptyset
signal/tst-sigisemptyset: relocation error: signal/tst-sigisemptyset: symbol pthread_sigmask version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference

But it is expected.  What I am missing here?