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

[Adhemerval Zanella]

On 13/03/2020 10:40, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> 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?
> 
> Does the test executable use lazy binding?  Is this a load-time error
> or a run-time error?

It is using lazy biding (I am building with a toolchain built with 
buildmanyglibcs.py and default since there is no out-of-tree patches
the default is lazy).

> 
> Of course, there will always be an error, but the question is whether
> it is a load-time error or a failure later at run time.  Our position
> so far has been that glibc symbol changes will not cause lazy binding
> failures (something that once had significant value, but less so with
> widespread BIND_NOW usage).
>

Ok, I will rework the patch to force a load-time failure in such cases.