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

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

On 06/05/2021 09:50, Florian Weimer via Libc-alpha wrote:
> * H. J. Lu:
> 
>> On Thu, May 6, 2021 at 2:17 AM Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>> * H. J. Lu:
>>>
>>>> On Wed, May 5, 2021 at 1:48 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>
>>>>> On Wed, May 5, 2021 at 1:17 PM Florian Weimer via Libc-alpha
>>>>> <libc-alpha@sourceware.org> wrote:
>>>>>>
>>>>>> * Andreas Schwab:
>>>>>>
>>>>>>> When bison is rebuilt with a linker that contains binutils commit
>>>>>>> b293661219c, it no longer crashes, and this patch isn't needed.
>>>>>>
>>>>>> Hmm.  I worry we need to preserve compatibility with old binaries.  Not
>>>>>> everyone can do distribution bootstrap or has the source code to carry
>>>>>> it out.
>>>>>
>>>>> We never guarantee that applications linked against the old unversion
>>>>> glibc work with the versioned glibc today.  Otherwise, we don't need
>>>>> glibc version at all.
>>>>
>>>> We can hide symbols for undefined, weak, unversioned references
>>>> from the old versioned binaries.
>>>
>>> If it's okay to deliberately break backwards compatibility with some old
>>> binaries, wouldn't we not use a patch at all?  That's drop this patch
>>> and just use what's currently in the tree?
>>>
>>> I'm not sure which group of old binaries is more important (deliberate
>>> use of unversioned weak symbols in recent times vs binaries linked
>>> against glibc 2.0 using the accidentally).  If it's okay to break
>>> things, I'm leaning towards “no patch” (despite having spent quite some
>>> time on it).
>>
>> We should maintain backward compatibility with versioned binaries.   For
>> unversioned binaries, we can check DT_NEEDED with libpthread.so.6.
> 
> No, entirely unversioned binaries would break without per-symbol
> treatment, see the symbol table I posted.  Looking for libpthread.so.6
> won't fix that.


But is the gcc-2.7.2.3 you referred failing to run on master without the
symbol filtering?

And did we have historically libpthread support for libc without symbols 
versioning? 

Because my view is this symbol filtering hack is required to fix this
specific ABI abuse that developers used to check if the process is 
multi-thread. Is there any other case we are aiming to keep backward 
support?