From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by sourceware.org (Postfix) with ESMTPS id EC51B385BF9E for ; Wed, 17 Mar 2021 17:22:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EC51B385BF9E Received: by mail-qk1-x734.google.com with SMTP id a9so39612259qkn.13 for ; Wed, 17 Mar 2021 10:22:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/UE+2NCQ/UDWe2AHV/vnKaTcTHm7Jf+MB4rTGFy399A=; b=qW/+otR7ydt7fog0bZrzXWfwl/0NeEdkFUpv5gqy7tm6yM1TQ13MmLjBvHWoDhOYm0 3stAmgLXbRuH1WLH3m8dKw5r627YIeSqY32JzpiftyxTxU85PHNf5joYJXg+0rO7Il+r DRejSgr7YwQqR8nNT+bCZXWI9dXM03T6MVI1xw7h6wsejy9CqeEbbtEU0jo2jD5eYMy8 a7QJ4aJCuKXGO0i7uFcw2uk5R0bAmK9VKEmVDy/rz59/SPAJNpseMOUdESCjBJDphzSg XKJRxqOLLQwQiA9TtarcoylikhfTW/gUhHNnPq/f0YxpAmWyoJVIMptk/CROOfQMBICm rs7w== X-Gm-Message-State: AOAM533M365ldtOv1NK+nzXzfM8N534nSYko5BHS7gQA3BqqSYAX7yRa PQ0WTUjfXx56oNJTutKl1Ju8Zdk+GnEyrboR X-Google-Smtp-Source: ABdhPJwofmJjxQwf8xQWorH6oKhngdHuqAc2N7bPOFlqbFE2NZmm4PmUrDfk4cV2+UVGkg2hiKuajg== X-Received: by 2002:a05:620a:4e6:: with SMTP id b6mr213042qkh.157.1616001770196; Wed, 17 Mar 2021 10:22:50 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id d70sm18458850qkg.30.2021.03.17.10.22.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Mar 2021 10:22:49 -0700 (PDT) To: Florian Weimer Cc: libc-alpha@sourceware.org References: <3ab7ccc92585d17c3171cf375605b53252d6b9a9.1615914631.git.fweimer@redhat.com> <41a88cab-808e-c10e-a975-41cdd252c299@linaro.org> <5405bbad-3c70-4435-8815-59e84738c3fb@linaro.org> <87h7l93klm.fsf@oldenburg.str.redhat.com> <583d20d2-54fe-9c30-805e-7182e00965bc@linaro.org> <87v99p1zxh.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Subject: Re: [PATCH v3 08/37] nptl: Move pthread_once and __pthread_once into libc Message-ID: Date: Wed, 17 Mar 2021 14:22:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <87v99p1zxh.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 17:22:52 -0000 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?