From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH v3 08/37] nptl: Move pthread_once and __pthread_once into libc
Date: Wed, 17 Mar 2021 14:22:46 -0300 [thread overview]
Message-ID: <b02089b1-3fe4-3b8b-0308-cb7fb9033eb7@linaro.org> (raw)
In-Reply-To: <87v99p1zxh.fsf@oldenburg.str.redhat.com>
On 17/03/2021 13:56, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> On 17/03/2021 11:45, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> On 17/03/2021 10:30, Adhemerval Zanella wrote:
>>>>>
>>>>>
>>>>> On 16/03/2021 14:28, Florian Weimer via Libc-alpha wrote:
>>>>>> And also the fork generation counter, __fork_generation. This
>>>>>> eliminates the need for __fork_generation_pointer.
>>>>>>
>>>>>> call_once remains in libpthread and calls the exported __pthread_once
>>>>>> symbol.
>>>>>>
>>>>>> pthread_once and __pthread_once have been moved using
>>>>>> scripts/move-symbol-to-libc.py.
>>>>>
>>>>> LGTM, I just don't see why we need a GLIBC_2.34 __pthread_once.
>>>>
>>>> Ok, it is called by call_once. I wonder if we could make a GLIBC_PRIVATE
>>>> instead so we can remove it once we moce call_once to libc.
>>>
>>> nss_ldap-253-16.el4 and nss_ldap-253-52.el5_11.2 use it, but those are
>>> doubly obslete (old releases, nss_ldapd is a secure replacement of
>>> nss_ldap).
>>
>> But those will bind to compat symbols, won't they?
>
> Yes, they would use compat symbols, but might not be re-linkable in a
> new build.
>
>>> We could turn __pthread_once into a compat symbol, but maybe we should
>>> handle this in consistent fashion for all libpthread __ symbols that do
>>> not have apparent external users?
>>
>> But right now the requirement is only for internal glibc usage over
>> libraries, by putting on GLIBC_PRIVATE it prevents the previous issues
>> where we export such internal symbols by accident (and it then force
>> us to keep providing them indefinitely).
>
> nss_ldap would silently link to __pthread_once@@GLIBC_PRIVATE instead
> after a rebuild. That's not a step forward, I think.
From nss_ldap from where exactly the __pthread_once will be originated?
I would expect that building it against 2.34 headers to reference
pthread_once instead.
>
>>> From a tactical perspective, maybe we should postpone this conversion to
>>> some pointer later in this release cycle. We would have to change the
>>> symbol name in glibc because it wouldn't make sense to have a non-compat
>>> GLIBC_PRIVATE symbol and a compat symbol at the same version (users
>>> would just link to the GLIBC_PRIVATE symbol). If everything is in libc,
>>> we can simply use libc_hidden_proto, without renaming internal use.
>>
>> It might be a better approach indeed, or maybe move call_once first and
>> then pthread_once.
>
> The same issue arises for many of the other __pthread_* symbols that
> historically used public symbol versions.
>
> Technically, to achieve linknamespace cleanliness, a C++ implementation
> might have to use __ names, too. libstdc++ does not do this for pthread
> symbols right now, though, except for __pthread_key_create for some
> strange reason. I spoke to Jonathan about this, and it's presently not
> a major concern. So I expect most of these symbols to be truly unused
> today, and we could indeed turn them into compat symbols. But as I
> said, having GLIBC_PRIVATE symbols at the same names would be
> counterproductive.
Right, does call pthread_once from call_once incur in a linknamespace
issue?
next prev parent reply other threads:[~2021-03-17 17:22 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 17:27 [PATCH v3 00/37] libpthread removal: NPTL forwarders are gone Florian Weimer
2021-03-16 17:27 ` [PATCH v3 01/37] nptl: Move pthread_mutex_consistent into libc Florian Weimer
2021-03-17 11:36 ` Adhemerval Zanella
2021-03-16 17:27 ` [PATCH v3 02/37] nptl: Move __pthread_cleanup_routine " Florian Weimer
2021-03-16 17:27 ` [PATCH v3 03/37] nptl: Move legacy unwinding implementation " Florian Weimer
2021-03-16 17:27 ` [PATCH v3 04/37] nptl: Move legacy cancelation handling into libc as compat symbols Florian Weimer
2021-03-16 17:27 ` [PATCH v3 05/37] nptl: Remove longjmp, siglongjmp from libpthread Florian Weimer
2021-03-17 11:38 ` Adhemerval Zanella
2021-03-16 17:28 ` [PATCH v3 06/37] x86: Restore compile-time check for shadow stack pointer in longjmp Florian Weimer
2021-03-16 17:28 ` [PATCH v3 07/37] nptl: Move __pthread_cleanup_upto into libc Florian Weimer
2021-03-16 17:28 ` [PATCH v3 08/37] nptl: Move pthread_once and __pthread_once " Florian Weimer
2021-03-17 13:30 ` Adhemerval Zanella
2021-03-17 13:37 ` Adhemerval Zanella
2021-03-17 14:45 ` Florian Weimer
2021-03-17 16:39 ` Adhemerval Zanella
2021-03-17 16:56 ` Florian Weimer
2021-03-17 17:22 ` Adhemerval Zanella [this message]
2021-03-17 17:43 ` Florian Weimer
2021-03-17 19:09 ` Adhemerval Zanella
2021-03-16 17:29 ` [PATCH v3 09/37] nptl: Move __pthread_unwind_next " Florian Weimer
2021-03-17 19:42 ` Adhemerval Zanella
2021-03-17 19:54 ` Florian Weimer
2021-03-17 20:16 ` Adhemerval Zanella
2021-03-17 20:33 ` Florian Weimer
2021-03-17 20:44 ` Adhemerval Zanella
2021-03-16 17:29 ` [PATCH v3 10/37] csu: Move calling main out of __libc_start_main_impl Florian Weimer
2021-03-17 20:45 ` Adhemerval Zanella
2021-03-16 17:29 ` [PATCH v3 11/37] nptl: Move internal __nptl_nthreads variable into libc Florian Weimer
2021-03-18 12:42 ` Adhemerval Zanella
2021-03-16 17:29 ` [PATCH v3 12/37] nptl_db: Introduce DB_MAIN_ARRAY_VARIABLE Florian Weimer
2021-03-18 12:43 ` Adhemerval Zanella
2021-03-16 17:29 ` [PATCH v3 13/37] nptl: Move __pthread_keys global variable into libc Florian Weimer
2021-03-18 12:44 ` Adhemerval Zanella
2021-03-16 17:29 ` [PATCH v3 14/37] nptl: Move __nptl_deallocate_tsd " Florian Weimer
2021-03-18 12:46 ` Adhemerval Zanella
2021-03-18 17:16 ` Florian Weimer
2021-03-18 17:54 ` Adhemerval Zanella
2021-03-16 17:29 ` [PATCH v3 15/37] nptl: Move pthread_exit " Florian Weimer
2021-03-18 12:49 ` Adhemerval Zanella
2021-03-16 17:29 ` [PATCH v3 16/37] nptl: Move pthread_setcancelstate " Florian Weimer
2021-03-18 12:52 ` Adhemerval Zanella
2021-03-16 17:29 ` [PATCH v3 17/37] nptl: Move pthread_setcanceltype " Florian Weimer
2021-03-18 12:53 ` Adhemerval Zanella
2021-03-16 17:29 ` [PATCH v3 18/37] nptl: Invoke the set_robust_list system call directly in fork Florian Weimer
2021-03-18 12:54 ` Adhemerval Zanella
2021-03-16 17:30 ` [PATCH v3 19/37] dlfcn: Failures after dlmopen should not terminate process [BZ #24772] Florian Weimer
2021-03-19 19:56 ` Adhemerval Zanella
2021-03-27 16:57 ` Florian Weimer
2021-03-16 17:30 ` [PATCH v3 20/37] dlfcn: dlerror needs to call free from the base namespace [BZ #24773] Florian Weimer
2021-03-23 14:47 ` Adhemerval Zanella
2021-03-16 17:30 ` [PATCH v3 21/37] Remove pthread_key_create-related internals from libc-lock.h Florian Weimer
2021-03-23 16:39 ` Adhemerval Zanella
2021-03-16 17:30 ` [PATCH v3 22/37] elf: Introduce __tls_init_tp for second-phase TCB initialization Florian Weimer
2021-03-23 18:25 ` Adhemerval Zanella
2021-03-16 17:30 ` [PATCH v3 23/37] nptl: Move part of TCB initialization from libpthread to __tls_init_tp Florian Weimer
2021-03-24 13:56 ` Adhemerval Zanella
2021-03-27 17:19 ` Florian Weimer
2021-03-16 17:30 ` [PATCH v3 24/37] nptl: Move pthread_key_create, __pthread_key_create into libc Florian Weimer
2021-03-24 14:09 ` Adhemerval Zanella
2021-03-24 14:32 ` Florian Weimer
2021-03-24 14:42 ` Adhemerval Zanella
2021-03-24 15:08 ` Florian Weimer
2021-03-24 15:46 ` Adhemerval Zanella
2021-03-16 17:30 ` [PATCH v3 25/37] nptl: Move pthread_getspecific, __pthread_getspecific " Florian Weimer
2021-03-24 14:12 ` Adhemerval Zanella
2021-03-24 14:38 ` Florian Weimer
2021-03-24 14:43 ` Adhemerval Zanella
2021-03-16 17:30 ` [PATCH v3 26/37] nptl: Move pthread_setspecific, __pthread_setspecific " Florian Weimer
2021-03-24 14:26 ` Adhemerval Zanella
2021-03-16 17:30 ` [PATCH v3 27/37] nptl: Move pthread_key_delete " Florian Weimer
2021-03-24 14:45 ` Adhemerval Zanella
2021-03-16 17:31 ` [PATCH v3 28/37] nptl: Move rwlock functions with forwarders " Florian Weimer
2021-03-25 19:52 ` Adhemerval Zanella
2021-03-27 21:41 ` Florian Weimer
2021-03-16 17:31 ` [PATCH v3 29/37] nptl: Move the internal thread priority protection symbols " Florian Weimer
2021-03-25 20:21 ` Adhemerval Zanella
2021-03-16 17:31 ` [PATCH v3 30/37] pthread: Introduce __pthread_early_init Florian Weimer
2021-03-25 20:22 ` Adhemerval Zanella
2021-03-16 17:31 ` [PATCH v3 31/37] nptl: Move internal symbol __mutex_aconf into libc Florian Weimer
2021-03-25 20:24 ` Adhemerval Zanella
2021-03-16 17:31 ` [PATCH v3 32/37] nptl: pthread_mutex_lock, pthread_mutex_unock single-threaded optimization Florian Weimer
2021-03-26 18:00 ` Adhemerval Zanella
2021-03-16 17:31 ` [PATCH v3 33/37] x86: Remove low-level lock optimization Florian Weimer
2021-03-25 20:30 ` Adhemerval Zanella
2021-03-16 17:31 ` [PATCH v3 34/37] nptl: Move core mutex functions into libc Florian Weimer
2021-03-25 20:46 ` Adhemerval Zanella
2021-03-16 17:31 ` [PATCH v3 35/37] nptl: Move core condition variable " Florian Weimer
2021-03-26 17:14 ` Adhemerval Zanella
2021-03-16 17:31 ` [PATCH v3 36/37] nptl: Move setxid broadcast implementation " Florian Weimer
2021-03-26 18:15 ` Adhemerval Zanella
2021-04-06 18:41 ` Florian Weimer
2021-04-06 18:54 ` Adhemerval Zanella
2021-04-06 19:23 ` Florian Weimer
2021-04-06 19:40 ` Adhemerval Zanella
2021-03-16 17:31 ` [PATCH v3 37/37] nptl: Remove remnants of the libc/libpthread forwarder interface Florian Weimer
2021-03-26 18:19 ` Adhemerval Zanella
2021-03-18 22:06 ` [PATCH v3 00/37] libpthread removal: NPTL forwarders are gone Florian Weimer
2021-03-26 18:25 ` Adhemerval Zanella
2021-03-31 10:18 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b02089b1-3fe4-3b8b-0308-cb7fb9033eb7@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).