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

[Florian Weimer]

* Adhemerval Zanella:

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

I can drop the __ symbols if you want.  With the string table, we can
add more symbols again if needed.

Most of the unversioned weak __pthread_mutex_lock references I have
actually come from our __libc_lock_lock macro.  (They are now strong
references obviously.)  However, someone copied that coding pattern into
the old nss_ldap module.  This suggests that there could be other cases.

Thanks,
Florian