From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 018803857424 for ; Tue, 15 Jun 2021 19:46:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 018803857424 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-83-z0tNCz7fMCGINYmlbsUEmA-1; Tue, 15 Jun 2021 15:46:51 -0400 X-MC-Unique: z0tNCz7fMCGINYmlbsUEmA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 68ADAC7405 for ; Tue, 15 Jun 2021 19:46:50 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-7.ams2.redhat.com [10.36.112.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 148CE1971B; Tue, 15 Jun 2021 19:46:46 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 15FJki273107829 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 15 Jun 2021 21:46:45 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 15FJkicr3107828; Tue, 15 Jun 2021 21:46:44 +0200 Date: Tue, 15 Jun 2021 21:46:44 +0200 From: Jakub Jelinek To: "Carlos O'Donell" Cc: Florian Weimer , libc-alpha@sourceware.org Subject: Re: [PATCH] nptl: Export _pthread_cleanup_push, _pthread_cleanup_pop again Message-ID: <20210615194644.GS7746@tucnak> Reply-To: Jakub Jelinek References: <87r1h3gnlx.fsf@oldenburg.str.redhat.com> <87y2bbey1n.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: Tue, 15 Jun 2021 19:46:57 -0000 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