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

[Florian Weimer]

* 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?

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).