[PATCH v3 09/37] nptl: Move __pthread_unwind_next into libc

[Adhemerval Zanella]

On 17/03/2021 17:33, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 17/03/2021 16:54, Florian Weimer wrote:
>>> * Adhemerval Zanella via Libc-alpha:
>>>
>>>> On 16/03/2021 14:29, Florian Weimer via Libc-alpha wrote:
>>>>> It's necessary to stub out __libc_disable_asynccancel and
>>>>> __libc_enable_asynccancel via rtld-stubbed-symbols because the new
>>>>> direct references to the unwinder result in symbol conflicts when the
>>>>> rtld exception handling from libc is linked in during the construction
>>>>> of librtld.map.
>>>>
>>>> From where exactly these come from? The *assynccancel should not be
>>>> generated for rtld-* objects.
>>>
>>> I think what happens is this: The libc.so objects that are used as a
>>> starting point have them, so the reducer tries to link in those symbols,
>>> and that fails with symbol conflicts.
>>
>> Right, but why doesn't it happen with other symbols that might be
>> pulled as well? It not a blocker, but I am trying to understand why
>> we are seeing this behavior with this change.
> 
> Ah, the explanation is quite trivial: We used to have a forwarder for
> __pthread_unwind, and that acted as a firewall for the rtld symbol set
> discovery.  Now the forwarder is gone, so the implementation of
> __pthread_unwind starts to matter.
> 
> Maybe I should stub out __pthread_unwind instead?  But doing it for the
> cancellation feels more natural.

The cancellation stub are fine, the long term goal is to remove them
anyway.