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

[Florian Weimer]

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

Thanks,
Florian