Re: [PATCH] nptl: Export _pthread_cleanup_push, _pthread_cleanup_pop again

[Carlos O'Donell <carlos@redhat.com>]

On 6/15/21 3:19 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 6/15/21 11:21 AM, Florian Weimer via Libc-alpha wrote:
>>> These were turned into compat symbols as part of the libpthread
>>> move.  It turns out they are used by language run-time libraries
>>> (e.g., the GCC D front end), so it makes to preserve them as
>>> external symbols even though they are not declared in any header
>>> file.
>>>
>>> Tested on i686-linux-gnu, x86_64-linux-gnu.  Built on i686-gnu.  (No
>>> full build on all ABIs, but the ABI update was done with
>>> update-all-abi.)
>>
>> Just like the pthread min stack size problem this is something we can't
>> change until we work with the runtime authors to avoid the regression or
>> get interfaces they need defined.
>>
>> Thanks for working through this issue. This change is straight forward,
>> we aren't at ABI freeze yet, and so this looks good to me.
> 
> Just to be clear, this is a public interface, not a GLIBC_PRIVATE one.
> It's just an old interface that unexpectedly has current users.

As an interface with a leading underscore it is part of the implementation
and should only have been called by macros under the control of the
implementation. There is perhaps a digression here, is the "D" runtime in
gcc a part of the implementation formed with glibc? If your answer is "Yes"
then the libphobos implementation that calls _pthreaed_cleanup_[push,pop]
is valid code to have in the compiler. However, my opinion is that core
language runtimes should not be calling leading underscore functions, and
that there should be a stronger separation between the language runtime
and the core runtime functionality. That requires we talk to more language
runtime developers to ensure we provide the functionality they need and
that we provide that functionality in some way. They should definitely
not be calling GLIBC_PRIVATE functions, but they do, because of missing
functionality in public interfaces.

-- 
Cheers,
Carlos.