[PATCH] nptl: Export _pthread_cleanup_push, _pthread_cleanup_pop again
Jakub Jelinek
jakub@redhat.com
Tue Jun 15 19:46:44 GMT 2021
On Tue, Jun 15, 2021 at 03:35:56PM -0400, Carlos O'Donell 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.
Languages like D can't use the C headers glibc provides.
And, this isn't something to gcc, it has been in all the D implementations
for ~ 13 years already:
https://github.com/dlang/druntime/blame/master/src/core/sys/posix/pthread.d
Jakub
More information about the Libc-alpha
mailing list