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

["H.J. Lu" <hjl.tools@gmail.com>]

On Wed, May 5, 2021 at 11:15 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * 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.

Why can't we just hide symbols for undefined, weak, unversioned references
from the old binaries?

-- 
H.J.