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

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 05/05/2021 14:19, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>> But that is not why my patch contains a symbol table: Once we detect an
>>> old binary, we need to treat certain symbols differently.  There are
>>> actually unversioned weak references to pthread_mutex_lock out there.
>>> pthread_mutex_lock@@GLIBC_2.0 has existed in libc.so.6 for a long time,
>>> so we need to bind such weak references to a definition.  In contrast,
>>> __pthread_mutex_lock@@GLIBC_2.0 only existed in libpthread.so.0 in glibc
>>> 2.33 and earlier.  This is why there is a table of magic symbols.  It's
>>> not to detect old binaries, it's there to record certain symbols which
>>> were historically part of libpthread.so.0 only.  That is a property of
>>> past binaries; as such it won't change with future glibc versions.
>>> That's why I think we need to encode that symbol set somewhere.  And a
>>> sorted table is a low-tech version to implement that.
>>
>> I am trying to understand which scenario the _dl_pthread_hidden_symbol is
>> required where the first part of dl_pthread_hide_symbol can't find that the
>> symbol should be hidden.
> 
> glibc 2.34 defines both pthread_mutex_lock@GLIBC_2.0 and
> __pthread_mutex_lock@GLIBC_2.0 in libc.  glibc 2.33 and earlier only
> defined pthread_mutex_lock@@GLIBC_2.0 in libc.
> 
> There are old binaries out there that contain unversioned weak
> references to pthread_mutex_lock or to __pthread_mutex_lock, without
> linking against libpthread.  To preserve backwards compatibility,
> pthread_mutex_lock must be bound to the function symbol in libc, but
> __pthread_mutex_lock must not be bound.

From where unversioned weak __pthread_mutex_lock come from and how are
they generated? It seems another interface abuse and I am not sure if we
should keep backwards compatibility for double underscore symbols. 

> 
> That's why I think we need to tell the two symbols apart.  There are of
> course many ways to encode the difference.  A name-based check seemed
> the most straight-forward approach to me.  It is an implementation
> detail.  With link editor support or binary rewriting, we could come up
> with alternative approaches (e.g., a bitmap containing a bit for each
> symbol table entry).  I'm not sure if that would result in code size
> savings though.
> 
> Thanks,
> Florian
>