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

[Adhemerval Zanella]

On 05/05/2021 13:01, Florian Weimer wrote:
> * H. J. Lu:
> 
>> On Wed, May 5, 2021 at 8:33 AM Adhemerval Zanella via Libc-alpha
>> <libc-alpha@sourceware.org> wrote:
> 
>>> On 05/05/2021 10:44, 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.
>>>>
>>>> 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.
>>> Can we postpone this fix until we get all the symbols from libpthread
>>> properly moved? I really dislike the symbol filter list, it is error
>>> prone and add unnecessary code size.
>>
>> Agreed.   We should just check one symbol, version, ABI note or property.
>> It shouldn't be too hard to do.
> 
> My patch checks for the presence of libpthread.so.0 and GLIBC_2.34.  I
> think the latter corresponds to your “one check” rule.  (We obviously
> need to disable all the magic in case libpthread.so.0 is present because
> then the symbols would be bound even on older glibc versions.)
> 
> 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.