Re: [RFC] elf: Implement filtering of symbols historically defined in libpthread

["H.J. Lu via Libc-alpha" <libc-alpha@sourceware.org>]

On Wed, Apr 28, 2021 at 1:37 PM Florian Weimer via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> Definitions of these symbols in libc expose bugs in existing binaries
> linked against earlier glibc versions.  Therefore, hide these symbols
> for old binaries.
>
> The symbol list in sysdeps/nptl/dl-pthread-weak.c contains some
> symbols which have not been moved yet, but that is harmless because
> the function is only invoked if the symbol is found in libc.so.
>
> The test suite passes on i686-gnu-linux, powerpc64-linux-gnu,
> x86_64-linux-gnu with these changes.
>
> Is this the direction we want to go in?  Then I'm going to add test
> cases, probably using assembler.
>
> Personally I think it's not *too* bad, also not particularly nice
> either.  elf/dl-pthread-weak.os brings in 2-3 KiB of code (but few
> run-time relocations).  One possibility I have not mentioned in the
> comment is to put the moved symbols into a GLIBCPTHREAD_2.34 symbol
> version and use the presence of this version on the chain as an
> indicator that the symbol uses special treatment.  This eliminates the
> separate string table.  The downside is that we cannot easily add more
> symbols if we discover some are missing.  This happened to me during
> development with pthread_mutexattr_gettype, which is a GLIBC_2.1 symbol
> and therefore not actually suitable for detecting the presence of
> libpthread (historically speaking).  And it could happen again with
> thrd_exit (which is of course much younger).
>

Since we want to detect the binaries which were linked against glibc
older than 2.34, we should use the glibc version to check the old
binaries.  Of course, we should make a complete list of functions
which are really implemented in libpthread.so and will be moved to
libc.so in glibc 2.34.

H.J.