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

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* Florian Weimer via Libc-alpha:

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

I'd appreciate if someone could have a look at this patch in tell me if
the approach is reasonable, all things considered.

  <https://sourceware.org/pipermail/libc-alpha/2021-April/125564.html>

Thanks,
Florian