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

[Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>]

On 28/04/2021 15:01, Florian Weimer via Libc-alpha wrote:
> Definitions of these symbols in libc expose bugs in existing binaries
> linked against earlier glibc versions.  Therefore, hide these symbols
> for old binaries.

It is unfortunate that we didn't specify that redefine libc symbol
visbility regarding elf linking should be considered undefined 
behaviour, so programs now rely un such behaviour (the bug foward
compatibility is such a messy constraint...).  It would be better if 
we knew earlier that a single thread API indication might just avoided 
this mess.

In any case I don't see a better way than moving the logic to loader
to handle such cases, the LD_PRELOAD is not really a solution. 

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

My take on this is to postpone the 2.34 release until we have the
libpthread/librt *fully* integrate on libc.so.  The half way through
only add unecessary complexity and it might avoid the 2-3 KiB binary
increase in code .