From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) by sourceware.org (Postfix) with ESMTPS id 2E5A73858C27 for ; Fri, 26 Mar 2021 18:25:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2E5A73858C27 Received: by mail-qv1-xf2e.google.com with SMTP id dc12so3407947qvb.4 for ; Fri, 26 Mar 2021 11:25:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=laUSD0SfLWJ6+RsmfXaK/eZhxBarmPhILRqsiNocEfo=; b=Lk3XkeQIGhvWBOSUJheYbNLrtRQQyCFC2f99hGAhZk/IsY13soSw8ZYBHZUzMOnbUC kU4kcMsvYlnPf4tuedOV1ktzT3c/qPGVF1S0uAm3yvJaxmuiCLGBveVG32yJbzK1zD8S It/o41aJc+EmDq95CRHphzgwbyGgv1unw6S954BreBS3yWfdVgEdU+jO7Dg67FaSoV1b g57iDjauoT9U5D2XsdT66UsDK+n1aCx9ea3KNE1PZIdey43B8LfTB9VXkNZ/sG2rRSMg MKacnfSAG3B0V2GFHn1n8QVRevBc7pTAF6zAgEq6F1ybbbbfovBHN8eAShS6pe+Q7cng YTJQ== X-Gm-Message-State: AOAM532ZW+BGIfYHXevvre7RsX02/zHBJ6OjGaXpnbwusijI2FPM706W rA9pLQWLElIVsYWUKEihFvjrM38mkNS8PUXL X-Google-Smtp-Source: ABdhPJyxEAdxdHZA6eYKGrWrTlye3eG3dppDIli9ekUpaUJCCtJPH8eFB0mLM+2XOIWPZTQIfoeFdw== X-Received: by 2002:a05:6214:88:: with SMTP id n8mr14693533qvr.22.1616783103753; Fri, 26 Mar 2021 11:25:03 -0700 (PDT) Received: from [192.168.1.132] ([177.194.41.149]) by smtp.gmail.com with ESMTPSA id h62sm7132436qkf.116.2021.03.26.11.25.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Mar 2021 11:25:03 -0700 (PDT) Subject: Re: [PATCH v3 00/37] libpthread removal: NPTL forwarders are gone To: libc-alpha@sourceware.org, Florian Weimer References: From: Adhemerval Zanella Message-ID: Date: Fri, 26 Mar 2021 15:25:01 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.5 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: Fri, 26 Mar 2021 18:25:05 -0000 On 16/03/2021 14:27, Florian Weimer via Libc-alpha wrote: > This series gets us to the point where no libc → libpthread function > forwarding exists anymore. It has been tested on i686-linux-gnu and > x86_64-linux-gnu, and built by build-many-glibcs.py. (A full bootstrap > cycle is still under way.) > > I incorporated Adhemerval feedback and his suggestion for keeping a > static assert. > > The TSD changes sort-of depend on the dlerror cleanup I originally > posted separately, so I'm including them here as well. > > The _Unwind_GetCFA cleanup is gone because I've pushed that separately. > > The additional patches are basically more of the same, except that I had > to move some of the libpthread early initialization into ld.so, so that > previously impossible scenarios (like calling pthread_key_create without > linking in libpthread) become supported. This series does not add tests > to cover those scenarios. Similarly, I have to initialize more libc > configuration things from __libc_early_init because those variables live > in libc, not ld.so. > > I had to remove the x86 low-level lock optimization, and redid it at the > mutex level. This way, it now works even if libpthread is linked in. > This was a change I wanted to make eventually anyway, but it turns out > the libpthread move invalidated the optimization (similar to the generic > optimization we had for private mutexes), so I had to do something about > it. > > I moved the mutex and conditional variable functions in two blocks > because of the many interdependencies, and the potential breakage from > real/stub implementation mismatches. > > Obviously, a lot of work still remains to do, but I believe at this > stage, we are already in a much better shape when it comes to late > loading of libpthread because we no longer use any stub implementations > that produce state the real implementations cannot consume. Hi Florian, I think I reviewed all the patches on the set and it looks good in general. Most changes are related to to your own patch that add the multiple reference support to compat_symbol, the remaining as mostly some question regarding the code and small nits. >From my side there is no need to resend the patches that need rebase, so I think the set should be good to push upstream once you adjust against master.